Настройка Network Policies в Kubernetes: практическое руководство по изоляции микросервисов

Настройка Network Policies в Kubernetes: практическое руководство по изоляции микросервисов

Архитектура безопасности Kubernetes по умолчанию опирается на плоскую сетевую модель: любой Pod в кластере может свободно отправлять сетевые пакеты любому другому Pod независимо от пространства имен (Namespace). В случае компрометации одного уязвимого веб-сервиса злоумышленник получает возможность свободно сканировать внутреннюю сеть и атаковать базы данных, платежные шлюзы и служебные интерфейсы (Lateral Movement).

Решением этой проблемы является переход на модель нулевого доверия (Zero Trust) с использованием стандартного ресурса Kubernetes — NetworkPolicy. Сетевая политика выступает в роли декларативного межсетевого экрана (Firewall) L3/L4 уровней OSI, ограничивая входящий (Ingress) и исходящий (Egress) трафик по меткам (Labels), пространствам имен и портам.

Важное условие: роль CNI-плагина

Официальная документация Kubernetes Network Policies подчеркивает ключевую особенность: сам по себе API-ресурс NetworkPolicy не обеспечивает фильтрацию трафика. Для реального соблюдения правил в кластере должен быть установлен сетевой CNI-плагин с поддержкой enforcement — например, Calico, Cilium или Kube-router. Если кластер использует стандартный Flannel без дополнительных модулей, созданные манифесты политик будут игнорироваться.

Стратегия «Default Deny»: Запретить всё

Правильный паттерн построения сетевой безопасности начинается с полного запрета любого неавторизованного трафика в рамках пространства имен. Только после закрытия всех портов создаются точечные разрешающие правила.

Манифест полного запрета входящего и исходящего трафика (default-deny-all.yaml):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Пустой селектор podSelector: {} означает, что политика применяются ко всем Pods в пространстве имен production, а отсутствие секций ingress и egress мгновенно блокирует весь внешний и межсервисный трафик.

Аддитивная семантика разрешений

Важно понимать ключевой принцип работы сетевых политик Kubernetes: разрешения складываются по логическому «ИЛИ» (аддитивно). Если к одному Pod применяются три разных манифеста NetworkPolicy, разрешающих входящий трафик от разных источников, Pod будет принимать пакеты от всех трех источников. В Kubernetes нет концепции «запрещающего правила с более высоким приоритетом», поэтому построение безопасности всегда идет от общего запрета к точечным разрешениям.

Практический сценарий: изоляция Backend-сервиса

После применения базового запрета необходимо разрешить легитимный трафик. Для примера рассмотрим API-сервис с меткой app: backend, который должен принимать входящие запросы на порт 8080 только от Frontend-подов (app: frontend) и отправлять исходящие запросы в PostgreSQL на порт 5432.

Пошаговый порядок настройки и внедрения:

1. Разрешение DNS-трафика. Без доступа к CoreDNS поды не смогут резолвить имена сервисов. Создайте правило разрешения Egress на UDP/TCP порт 53 в пространство имен kube-system.
2. Применение политики сервиса. Создайте манифест с точечным разрешением портов и селекторов:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Наблюдаемость трафика и анализ Flow Logs

При внедрении строгих NetworkPolicies ключевой инженерной задачей становится отладка случайно заблокированных соединений. В современных CNI-плагинах (например, Cilium Hubble или Calico Flow Logs) предусмотрены встроенные средства наблюдаемости сетевого трафика.

Инженеры могут просматривать сетевой поток в реальном времени:

• Анализировать блокировки с флагом DROPPED для выявления пропущенных правил;
• Видеть точные имена пространств имен, меток Pod и портов, на которых произошел сброс пакета;
• Проверять отсутствие дублирующего трафика и нежелательных опросов здоровье (Health checks).

Особые случаи: трафик hostNetwork и узлов кластера

Сетевые политики Kubernetes имеют границу применимости. В частности, они не контролируют трафик подов, запущенных в режиме hostNetwork: true (например, некоторых ингресс-контроллеров или системных демонов), а также прямого трафика от нод кластера. Такие соединения должны защищаться на уровне внешних Firewall и настроек хостового IPTables/NFTables.

Проверка и верификация правил

Для подтверждения корректности работы политик выполните обязательные проверки работоспособности:

• Положительный тест: выполните команду проверки связи из разрешенного Pod: kubectl exec -n production -it deploy/frontend -- curl -m 5 http://api-backend:8080/health Ожидаемый результат: успешный ответ HTTP 200;
• Отрицательный тест: выполните ту же команду из неавторизованного тестового Pod: kubectl exec -n production -it deploy/unauthorized -- curl -m 5 http://api-backend:8080/health Ожидаемый результат: таймаут соединения (Connection Timed Out).

Процедура аварийного отката (Rollback)

Перед внедрением правил в продакшен необходимо иметь заранее подготовленный и проверенный сценарий отката. В случае непредвиденной блокировки бизнес-трафика инженеры должны быстро применить либо удаление блокирующей политики, либо временный манифест разрешения без удаления основного diff, что сохраняет возможность последующего расследования причин инцидента.

Ограничения модели и L7-безопасность

Стандартный ресурс NetworkPolicy работает исключительно на L3/L4 уровнях OSI (IP-адреса и TCP/UDP порты). Он не умеет фильтровать HTTP-методы (GET vs POST), анализировать URL-пути или проверять пользовательские токены. Для защиты на L7-уровне требуется применение Service Mesh (Cilium Service Mesh, Istio) или Layer 7 политик CNI.

Внедрение NetworkPolicies предотвращает распространение атак внутри кластера и является обязательным стандартом для подготовки инфраструктуры к сертификации по требованиям безопасности PCI-DSS и ГОСТ.