Что такое NetworkPolicy в Kubernetes?

Что такое NetworkPolicy в Kubernetes

NetworkPolicy — это объект Kubernetes, который определяет правила сетевого доступа для Pod'ов, позволяя контролировать входящий (ingress) и исходящий (egress) трафик на уровне L3 (IP-адреса) и L4 (порты/протоколы). По умолчанию в Kubernetes все Pod'ы могут свободно общаться друг с другом, что создаёт риски для безопасности в production-средах. NetworkPolicy решает эту проблему, реализуя модель "запрещено по умолчанию" (default-deny) или сегментацию сети через микросетевое разграничение (microsegmentation).

Ключевые особенности и принципы работы

• Действует на уровне Pod'ов: Правила применяются к группам Pod'ов, выбранным через селекторы (label selectors), а не к отдельным контейнерам или узлам.
• Зависит от сетевого плагина: Для реализации NetworkPolicy требуется CNI-плагин (Container Network Interface), поддерживающий политики, например Calico, Cilium, Weave Net или Antrea. Без такого плагина создание NetworkPolicy не даст эффекта.
• Изолирующее поведение: Если Pod попадает под действие хотя бы одной NetworkPolicy, он теряет "разрешительный по умолчанию" доступ — теперь разрешён только трафик, явно описанный в правилах.

Структура NetworkPolicy

Базовая структура манифеста включает:

• podSelector: Выбор Pod'ов, к которым применяется политика (пустой podSelector: {} означает "все Pod'ы в namespace").
• policyTypes: Указывает типы правил — Ingress, Egress или оба.
• ingress/egress rules: Конкретные правила доступа с указанием источников, назначений, портов и протоколов.

Примеры NetworkPolicy

1. Запрет всего входящего трафика (default-deny ingress)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}  # Применяется ко всем Pod'ам в namespace
  policyTypes:
  - Ingress
  ingress: []  # Пустой список — запрет любого входящего трафика

2. Разрешение доступа только от определённых Pod'ов

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-backend
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend  # Разрешаем ingress только от Pod'ов с label app=backend
    ports:
    - protocol: TCP
      port: 80

3. Контроль исходящего трафика (egress)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24  # Разрешаем egress только в указанную подсеть
    ports:
    - protocol: TCP
      port: 5432  # PostgreSQL

Сценарии использования в DevOps-практике

• Защита баз данных: Изоляция Pod'ов с СУБД, разрешая доступ только от определённых backend-сервисов.
• Многоуровневая архитектура: Сегментация между фронтендом, бэкендом и слоем данных в соответствии с принципом least privilege.
• Комплаенс и безопасность: Соответствие требованиям стандартов (PCI DSS, HIPAA) через аудит и ограничение сетевых потоков.
• Защита от lateral movement: Предотвращение "перемещения" атакующего между скомпрометированными Pod'ами в кластере.

Важные ограничения и нюансы

• Отсутствие правил для DNS: Частая ошибка — блокировка egress на порт 53 для DNS, что ломает разрешение имён внутри кластера. Решение — явное разрешение доступа к kube-dns:

egress:
- to:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        k8s-app: kube-dns
  ports:
  - protocol: UDP
    port: 53

• Порядок правил: NetworkPolicy не имеют приоритетов — правила аддитивны (объединяются через логическое "ИЛИ").
• Нет поддержки L7: Стандартный NetworkPolicy работает только на уровнях L3-L4. Для фильтрации HTTP/gRPC-трафика требуется расширение (например, Cilium NetworkPolicy или Istio AuthorizationPolicy).

Заключение

В DevOps-инфраструктуре NetworkPolicy — критический инструмент для реализации security-in-depth, особенно в мультитенантных или compliance-чувствительных средах. Хотя их настройка добавляет сложности, они становятся необходимыми по мере роста кластера. Рекомендуется начинать с политик default-deny для production-неймспейсов и постепенно добавлять разрешающие правила по мере необходимости, документируя каждое изменение для поддержания ясности сетевой модели.