Перейти к содержанию

Доступ к сервисам

Hive разделяет трафик на internal и public по hostname. Это даёт безопасные дефолты: новый сервис не оказывается в открытом интернете, пока его явно туда не выставят.

Кратко

Где живёт сервис Кому доступен Когда использовать
Hive-домен ({name}.{namespace}.knative[-staging].svcik.org) Только из корпоративной сети + доверенные внешние сети Внутренние сервисы, dev/preview, API между микросервисами
customDomains (api.example.com и т.п.) Любой источник Сервисы, к которым ходят внешние пользователи/системы

Hive-домен есть всегда — он создаётся автоматически. customDomains добавляются по желанию в .hive.yml.

Internal: hive-домены

Любой сервис автоматически получает URL вида:

https://{name}.{namespace}.knative-staging.svcik.org   # staging
https://{name}.{namespace}.knative.svcik.org           # production

Доступ к этому URL разрешён только из:

  • Корпоративной сети — IP-allowlist синхронизируется с корпоративного api-sec (офисы, VPN, инфраструктура).
  • Cloudflare (v4/v6 ranges) — для трафика, который проходит через CF к customDomains.
  • Anthropic (160.79.104.0/21, 2607:6bc0::/48) — для outbound из Claude (например, MCP-tool-вызовы).

Запросы с любого другого IP получают 403 RBAC: access denied на уровне Istio gateway. До контейнера не доходят.

Это не приватная сеть

Hive-домен по-прежнему доступен из публичного интернета, но IP-фильтр пропускает только перечисленные сети. Это удобный практический "internal", не сетевая изоляция в кубернетесном смысле (нет mTLS, нет NetworkPolicy на уровне service mesh). Для критически чувствительных вещей закладывайтесь на дополнительные проверки в самом приложении.

Public: customDomains

Чтобы сервис был доступен извне корпоративной сети, добавьте customDomains: в .hive.yml:

name: my-public-api
port: 8080
customDomains:
  - api.example.com
  - app.example.com

После деплоя:

  1. Hive создаёт DomainMapping на каждый домен.
  2. cert-manager выпускает TLS-сертификат через Let's Encrypt (первый раз — до 1–2 минут).
  3. Запросы на api.example.com пропускаются без IP-фильтра — независимо от источника.
  4. Hive-домен того же сервиса (my-public-api.{namespace}.knative...svcik.org) остаётся internal.

DNS

Создайте у DNS-провайдера CNAME (или A-запись) на внешний gateway:

api.example.com.   CNAME   external-gateway.svcik.org

Точное целевое имя — у платформенной команды.

Поведение

Запрос Источник из allowlist Источник снаружи allowlist
https://my-svc.my-team.knative-staging.svcik.org/ 200 OK 403
https://api.example.com/ (customDomain) 200 OK 200 OK

То есть один и тот же сервис отвечает по двум URL с разными правилами доступа.

Как это устроено

Под капотом — hive-gatekeeper, отдельный контроллер в hive-core. Каждые 5 минут он:

  1. Тянет корпоративный IP-allowlist у api-sec.
  2. Подмешивает статические/динамические CIDR'ы из ConfigMap (Cloudflare, Anthropic, и т.п.).
  3. Список всех DomainMapping в кластере (= customDomains) превращает в отдельный allow-host list.
  4. Перезаписывает две AuthorizationPolicy на Gateway/eg-external в namespace envoy-gateway-system:
  5. hive-ip-allowlist — ALLOW from ipBlocks ... when host ∈ *.knative.svcik.org | *.knative-staging.svcik.org
  6. hive-customdomain-allow — ALLOW from any when host ∈ <список customDomains>

Всё что не подходит ни под одну — DENY by default (Istio default-deny при наличии хотя бы одной ALLOW policy).

Добавление новой доверенной сети

Если нужно дополнить IP-allowlist (новый партнёр, ещё один cloud-провайдер):

  1. Если у источника есть публичный URL со списком CIDR в plaintext (Cloudflare-style) — добавляется в sources: ConfigMap hive-gatekeeper-sources в hive-core. Обновится автоматически на следующем tick.
  2. Если опубликованного машинно-читаемого endpoint'а нет — статически в static: той же ConfigMap.
data:
  sources.yaml: |
    static:
      - 160.79.104.0/21
      - 2607:6bc0::/48
    sources:
      - name: cloudflare-v4
        url: https://www.cloudflare.com/ips-v4

Изменение применяется без рестарта pod'а — kubelet проливает обновлённый ConfigMap через volume mount.

Частые ошибки

"Сервис не отвечает извне", хоть деплой Healthy

Скорее всего обращаешься с домашнего/мобильного IP. Hive-домен не пропустит. Проверь:

curl -v https://my-svc.my-team.knative-staging.svcik.org/
# 403 RBAC: access denied

Решения:

  • Если сервис должен быть публичным — добавь customDomains: и обращайся по нему.
  • Если сервис внутренний — подключайся через VPN/из офиса.

403 от Cloudflare-proxy на customDomain

Cloudflare может скрыть оригинальный IP клиента. Если customDomain настроен без прокси (Cloudflare DNS only), запрос приходит с IP клиента — и hive-customdomain-allow всё равно его пропускает (там нет ipBlocks-фильтра). Если с прокси — приходит с IP Cloudflare, который тоже в allowlist (благодаря cloudflare-v4/v6 источникам). Так что 403 на customDomain — не норма; первое что проверить — правильно ли DomainMapping создался: kubectl get domainmapping -A.

Что дальше