Gymterview
middle

Что такое Network Policies в Kubernetes и как они защищают приложение?

Network Policy – это ресурс Kubernetes, определяющий правила сетевого взаимодействия между подами, работающий по принципу файрвола: можно ограничить как входящий (ingress), так и исходящий (egress) трафик.

По умолчанию в Kubernetes все поды могут свободно общаться друг с другом – это опасно, так как скомпрометированный под может обратиться к любому сервису в кластере (lateral movement).

Аналогия: Network Policy – как система пропусков в бизнес-центре. Без них любой может зайти на любой этаж. С ними – только туда, куда выписан пропуск.

Требования

Network Policies требуют CNI-плагин с поддержкой политик: Calico, Cilium, Weave Net. Стандартный flannel не поддерживает Network Policies – политики будут создаваться без ошибок, но не будут применяться.

Запрет всего трафика по умолчанию (deny all)

Пример
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: banking
spec:
  podSelector: {}  # Применить ко всем подам в namespace
  policyTypes:
  - Ingress
  - Egress

Это рекомендуемая отправная точка – начинаем с полного запрета, затем открываем только необходимое (whitelist-подход).

Разрешение входящего трафика от конкретного сервиса

Пример
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-payment-service
  namespace: banking
spec:
  podSelector:
    matchLabels:
      app: payment-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
    ports:
    - protocol: TCP
      port: 8080

Эта политика разрешает подам с меткой app: api-gateway подключаться к payment-service на порт 8080. Все остальные подключения к payment-service запрещены.

Разрешение исходящего трафика только к определённым сервисам

Пример egress-политики для payment-service
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-service-egress
  namespace: banking
spec:
  podSelector:
    matchLabels:
      app: payment-service
  policyTypes:
  - Egress
  egress:
  # Разрешить доступ к базе данных
  - to:
    - podSelector:
        matchLabels:
          app: postgres
    ports:
    - protocol: TCP
      port: 5432
  # Разрешить DNS-запросы (обязательно!)
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53
  # Разрешить доступ к Kafka
  - to:
    - podSelector:
        matchLabels:
          app: kafka
    ports:
    - protocol: TCP
      port: 9092

Изоляция namespace-ов

Пример политики изоляции namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-from-other-namespaces
  namespace: banking
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  # Разрешить трафик только из своего namespace
  - from:
    - podSelector: {}
  # Разрешить трафик из namespace мониторинга
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring

Типичная архитектура сетевых политик

Пример
Internet -> Ingress Controller -> API Gateway -> [Banking Services] -> Database
                                       |                 |
                                  Auth Service         Kafka
                                       |
                                     Vault

Каждая стрелка – отдельная Network Policy. Всё, что не разрешено явно, запрещено.

Вывод

Network Policies – обязательный элемент безопасности в Kubernetes. Подход deny-all + whitelist гарантирует, что каждый сервис может общаться только с теми компонентами, которые ему действительно нужны. Не забывайте разрешать DNS (порт 53), иначе под не сможет резолвить имена сервисов.

На собеседовании: покажите знание подхода deny-all + whitelist, объясните разницу между ingress и egress. Обязательно упомяните необходимость CNI-плагина с поддержкой политик (Calico, Cilium) и частую ошибку – забытый DNS в egress.