В Kubernetes-кластере после установки нового приложения выяснилось, что любой Pod в любом namespace может свободно подключаться к Pod'ам базы данных в namespace db, хотя ожидалось, что доступ должен быть только у приложения из namespace app. Как диагностировать и исправить ситуацию?

Короткий ответ

По умолчанию в Kubernetes сетевой трафик между Pod'ами не ограничен, если не применены NetworkPolicy и CNI-плагин, который их поддерживает; нужно проверить, поддерживает ли используемый CNI NetworkPolicy, и явно создать политику, разрешающую входящий трафик к Pod'ам БД только от Pod'ов приложения.

Как это работает подробнее

NetworkPolicy — это «allow-list» поверх сети, которая без политик полностью открыта (flat network) для трафика между всеми Pod'ами кластера. Если ни одна NetworkPolicy не выбирает Pod, трафик к нему не ограничен независимо от namespace. Важно: сами объекты NetworkPolicy ничего не делают, если установленный CNI-плагин (например, Flannel в базовой конфигурации) не реализует их применение — нужен CNI с поддержкой (Calico, Cilium, большинство managed-решений облаков).

Пример кода

security-example-459.yamlКопировать

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-from-app
  namespace: db
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: app
      ports:
        - protocol: TCP
          port: 5432

Что использовать на практике

• Практика. сначала проверяют, что CNI поддерживает NetworkPolicy (тестовой политикой deny-all и проверкой, действительно ли трафик блокируется), затем вводят политику «default deny» для namespace db и отдельно разрешают входящий трафик только от Pod'ов с нужным label/namespace через ingress.from.
• Проверка. Ожидаемое поведение: после применения политики подключение к Pod'у БД из namespace app продолжает работать (psql успешно подключается), а попытка подключения из произвольного другого namespace зависает/получает тайм-аут — это проверяется тестовым Pod'ом с nc -zv db-pod-ip 5432 в разных namespace.

Подводные камни

• Ошибка. создавать NetworkPolicy и считать проблему решённой без проверки, что CNI реально её применяет; забывать, что при отсутствии явного policyTypes: [Ingress] или selector'а политика может не покрывать нужный трафик; разрешать доступ по IP-диапазону namespace вместо label-селектора, что ломается при пересоздании Pod'ов с новыми IP.