Gateway API и Cilium Network Policies. Как ресурсы влияют друг на друга

Одновременная работа Gateway API и Cilium Network Policies в кластере, почему публикация через Gateway может внезапно сломаться после настройки политик, и что нужно знать, чтобы этого избежать.

В кластере могут быть одновременно настроены:

• Gateway API — управляет входящим трафиком: какие запросы и куда направлять.
• Cilium Network Policies — управляют безопасностью: кому можно общаться с кем. Сетевые политики Cilium в GUI.

Gateway проводит трафик через свой прокси, а политики решают, можно ли этому трафику пройти дальше. В платформе «Штурвал» используется Cilium с его встроенным контроллером Gateway API на основе Envoy. Поэтому описанная ниже модель с идентичностью reserved:ingress работает именно для этого сценария. Если вы используете сторонний Gateway-контроллер (например, Traefik, Istio, Envoy Gateway), механизмы будут другими — см. Настройка политик, если контроллер не Сilium.

Если настроить Gateway, но не создавать сетевых политик — трафик будет проходить. Проблемы могут возникнуть, когда на бэкенд уже действует запрещающая политика, а разрешение для Gateway не добавлено.

Подробнее о Gateway API на страницах:

• Gateway API — обзор модели, CRD, включение контроллера.
• Gateway Classes — GatewayClass.
• Gateways — точки входа Gateway, listeners.
• Маршруты Gateway API — HTTPRoute / GRPCRoute.
• CRD модуля Gateway API — установка CRD.
• Модуль управления сетями — gatewayAPI.enabled в Cilium.
• Ingress NGINX умер, да здравствует Gateway API — зачем уходить с Ingress.

1. Как это устроено #

1.1. Что происходит с трафиком, когда он проходит через Gateway #

Обычный Ingress-контроллер (например, Nginx) работает так: есть отдельные поды контроллера, которые принимают запросы и перенаправляют их в бэкенд. Политики безопасности в этом случае пишутся в стиле: “разрешить подам контроллера общаться с подами приложения”.

В Cilium Gateway API встроен в сетевой стек:

1. Запрос от клиента приходит на Service Gateway.
2. Cilium перехватывает этот трафик через eBPF и направляет его во встроенный прокси Envoy, который работает на каждом узле кластера.
3. Envoy применяет правила маршрутизации из HTTPRoute/GRPCRoute.
4. Трафик, который прошёл через Gateway, Cilium присваивает специальную идентичность — reserved:ingress (или просто ingress).

Что это значит для политик:

• Для бэкенда (вашего приложения) источником трафика становится Gateway, а не IP-адрес клиента.
• Поэтому правило “разрешить доступ с IP-адреса клиента” на бэкенде не сработает — политика увидит источник ingress, а не клиентский IP.
• Чтобы разрешить доступ от Gateway к бэкенду, нужно написать политику, которая разрешает идентичность ingress.

1.2. Два уровня контроля #

При использовании Gateway API возможно контролировать трафик политиками Cilium в двух точках:

2. Влияние ресурсов #

3. Identity reserved:ingress #

Это ключевая концепция:

Особенности настройки при использовании стороннего GatewayClass #

Если в качестве GatewayClass выбран не cilium, а сторонний контроллер (например, Traefik, Istio, Envoy Gateway), в этом случае:

1. Идентичность reserved:ingress не применяется — трафик идёт от обычных подов контроллера со своими метками.
2. Политики Cilium с fromEntities: [ingress] перестают работать — их нужно переписать под селекторы нового контроллера.

Как переписать политики #

Было (для Cilium Gateway):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: my-app
spec:
  endpointSelector:
    matchLabels:
      app: my-backend
  ingress:
    - fromEntities:
        - ingress   # ← не работает для стороннего контроллера

Стало (для стороннего контроллера):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: my-backend
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: gateway-system   # неймспейс контроллера
          podSelector:
            matchLabels:
              app: my-gateway-controller   # метки подов контроллера

Альтернативный вариант — через CiliumNetworkPolicy с селекторами #

Если вы хотите остаться в рамках CiliumNetworkPolicy, используйте селекторы по меткам вместо fromEntities:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: my-app
spec:
  endpointSelector:
    matchLabels:
      app: my-backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: my-gateway-controller
            io.kubernetes.pod.namespace: gateway-system

Что остаётся без изменений #

4. Рекомендации #

4.1. Для бэкенда: всегда разрешать ingress #

Основной способ: разрешить доступ от Gateway к приложению при настроенных политиках Cilium.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: my-app
spec:
  description: "Разрешить трафик от Cilium Gateway"
  endpointSelector:
    matchLabels:
      app: my-backend
  ingress:
    - fromEntities:
        - ingress
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

4.2. Для Gateway: контролировать, кто может до него достучаться #

Пример: разрешить доступ к Gateway только из определённой подсети

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: allow-cidr-to-ingress
spec:
  description: "Разрешить доступ к Gateway только из подсети X"
  endpointSelector:
    matchExpressions:
      - key: reserved:ingress
        operator: Exists
  ingress:
    - fromCIDRSet:
        - cidr: 203.0.113.10/32

4.3. Для Gateway: разрешить ходить в кластер #

Если в кластере включена изоляция, Gateway должен иметь возможность направлять трафик к бэкендам:

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: allow-ingress-to-cluster
spec:
  description: "Разрешить Gateway ходить в кластер"
  endpointSelector:
    matchExpressions:
      - key: reserved:ingress
        operator: Exists
  egress:
    - toEntities:
        - cluster

4.4. Вводить изоляцию по шагам #

Не включайте жёсткую изоляцию сразу:

1. Сначала добейтесь рабочего пути Gateway → бэкенд.
2. Добавьте политику allow from ingress.
3. Включите default-deny или примените селекторы.
4. Проверяйте Hubble до и после каждого шага.

4.5. Отлаживать через Hubble #

Hubble показывает реальные потоки трафика и вердикты политик:

# Посмотреть все заблокированные потоки в неймспейсе
hubble observe --verdict DROPPED --namespace my-app --last 50

# Посмотреть трафик от Gateway (identity ingress)
hubble observe --identity ingress --last 50

# Проверить статусы ресурсов
kubectl get gateway -A
kubectl get httproute -A
kubectl get cnp -n my-app

Ищите, на каком этапе обрыв: world ↔ ingress или ingress ↔ app.

4.6. Чего не стоит делать #

5. Примеры: манифесты для типовых сценариев #

5.1. Gateway #

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: gateway-system
spec:
  gatewayClassName: cilium
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
    - name: https
      protocol: HTTPS
      port: 443
      hostname: app.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: app-tls
            kind: Secret
      allowedRoutes:
        namespaces:
          from: Same

5.2. HTTPRoute #

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: my-app
spec:
  parentRefs:
    - name: my-gateway
      namespace: gateway-system
      sectionName: https
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080

5.3. Изоляция неймспейса с доступом от Gateway + DNS #

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: isolate-allow-gateway
  namespace: my-app
spec:
  description: "Default deny для неймспейса; разрешены Gateway и DNS"
  endpointSelector: {}
  ingress:
    - fromEntities:
        - ingress
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
        rules:
          dns:
            - matchPattern: "*"

5.4. Минимальный набор “Gateway + политики” #

# Бэкенд принимает трафик от Cilium Gateway
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: app-allow-gateway
  namespace: my-app
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  ingress:
    - fromEntities:
        - ingress
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchPattern: "*"
---
# Gateway может ходить в кластер
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: allow-ingress-to-cluster
spec:
  endpointSelector:
    matchExpressions:
      - key: reserved:ingress
        operator: Exists
  egress:
    - toEntities:
        - cluster

6. Проверки после настройки #

7. Коротко #

1. Gateway API и Cilium Network Policies — одна система datapath, а не два независимых слоя.
2. Между клиентом и приложением появляется промежуточное звено — Gateway-контроллер с identity ingress. Нужно разрешать трафик на двух участках: доступ к Gateway и доступ от Gateway к бэкенду.
3. Для бэкенда используйте CiliumNetworkPolicy с fromEntities: [ingress]. Стандартный NetworkPolicy работает ограниченно и ненадёжно.
4. Не фильтруйте клиентов по IP на бэкенде — источником для политики становится ingress. Делайте это на уровне Gateway, внешнего firewall или по HTTP-заголовкам (X-Forwarded-For, X-Envoy-External-Address) в приложении.
5. Не ожидайте per-Gateway разграничения через одну entity ingress — в текущей модели Cilium это пока невозможно.
6. Применяйте политики постепенно и проверяйте путь в Hubble.

Рекомендуется сначала добиться рабочего Gateway-пути, затем добавьте точечный allow от ingress, при необходимости делайте строже изоляцию.

Справка #

Identity (сущности Cilium) #

API-версии ресурсов #

Примеры команд #

# Проверка политик
kubectl get cnp -A
kubectl get ccnp

# Проверка Gateway
kubectl get gateway,httproute -A
kubectl describe gateway <name> -n <ns>

# Отладка через Hubble
hubble observe --verdict DROPPED --namespace <ns>
hubble observe --identity ingress --last 50