Настройка Kubernetes Network Policies для сетевой изоляции

Для production-кластера с 5 микросервисами требуется около 10 политик. Каждая включает Ingress и Egress правила. Ниже шаблон для типового сервиса с БД и кешем:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: service-a
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: service-a
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - port: 3000
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - port: 5432
    - to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - port: 6379
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP

Важный момент: в современных версиях Kubernetes namespaceSelector и podSelector в одном блоке from трактуются как AND. В более старых версиях — как OR. Проверьте версию вашего кластера, например, kubectl version --short.

Межнеймспейсное взаимодействие: allow-prometheus-scrape

Например, мониторинговый namespace должен собирать метрики с подов в production. Создаём разрешающую политику в namespace production:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-scrape
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app.kubernetes.io/name: prometheus
      ports:
        - port: 9090
          protocol: TCP

Проблема healthcheck и её решение

kubelet выполняет health-проверки с IP узла (node IP) к поду. Если политики блокируют входящий трафик от любых источников, kubelet не сможет выполнить probe. Решение — разрешить трафик от CIDR узлов кластера:

 ingress: - from: - ipBlock: cidr: 10.0.0.0/16 # CIDR нод кластера ports: - port: 8080 

Это предотвращает 95% проблем с healthcheck после внедрения политик.

Как отлаживать Network Policies?

Сложность в отсутствии логов блокировок в самом Kubernetes. Используйте специализированные инструменты:

• Calico: calicoctl get policy -n production показывает распарсенные правила; calicoctl node diags собирает состояние dataplane.
• Cilium: cilium monitor --type drop отображает отброшенные пакеты; hubble observe --namespace production --verdict DROPPED даёт статистику через Hubble UI. Cilium — один из самых производительных CNI с eBPF.

Без утилит: запустите pod с образом nicolaka/netshoot и проверяйте nc -zv postgres 5432.

Сравнение CNI-плагинов для Network Policies

Cilium в 2-3 раза быстрее Calico при фильтрации на уровне L7 благодаря eBPF. Для большинства продакшн-сценариев Calico достаточен, но если нужна глубокая наблюдаемость и высокая производительность — выбирайте Cilium. Flannel без дополнений не поддерживает политики, поэтому не рассматривайте его для изоляции.

Пошаговая настройка Network Policy

1. Аудит текущей сетевой топологии и модели безопасности — определите namespace и сервисы.
2. Проектирование политик на основе потоков: Ingress от Ingress-контроллера, Egress к базам данных.
3. Разработка манифестов с покрытием всех критичных потоков (не забывайте DNS!).
4. Тестирование на staging-окружении — проверьте healthcheck, dns, и работу приложений.
5. Документирование каждой политики и схемы изоляции для команды эксплуатации.

Типичные проблемы и ошибки Network Policies

Чаще всего (в 95% случаев) блокируется healthcheck — всегда добавляйте ipBlock для узлов. Также забывают про Egress к DNS и репликацию между репликами StatefulSet. Используйте kubectl describe networkpolicy для проверки.

Что входит в работу

• Аудит текущей сетевой топологии и модели угроз.
• Проектирование политик изоляции под ваш стёк (Calico/Cilium).
• Написание и применение манифестов (default deny + разрешающие правила).
• Тестирование всех критичных потоков (healthcheck, DNS, мониторинг).
• Документация схемы изоляции и runbook для операционной команды.
• Обучение инженеров работе с политиками (2-часовой workshop).

Стоимость типового проекта по настройке Network Policies — от $700–1.5k в зависимости от сложности и количества сервисов.

Сроки выполнения

• Простой кластер (3-5 сервисов в одном namespace) — 1-2 дня.
• Сложная топология с межнеймспейсным взаимодействием — до 3 дней.
• Полный аудит и внедрение в продакшн (включая документацию) — от 4 дней.

Обратитесь к нашим инженерам для аудита вашего кластера — рассчитаем сроки и объём работ под ваш проект. Закажите внедрение Network Policies под ключ: обеспечим безопасность без простоев.

Источник: Kubernetes Documentation