Сетевой контроль — одна из тех областей, где легко перестараться и получить либо дырявую безопасность, либо сломанный кластер. Network Policies в Kubernetes дают инструментальный набор для явного описания того, кто и как может разговаривать с вашими подами. В этой статье разберём, как эти правила работают, какие есть подводные камни и как аккуратно внедрять политики в продакшн, чтобы не отключить жизненно важные сервисы.
Зачем нужны сетевые политики
В современном кластере приложения общаются между собой по сети постоянно. Без явных ограничений любой под может подключиться к любому другому — это удобно, но опасно при наличии уязвимостей или мультиарендной нагрузки. Политики позволяют перевести модель безопасности из «всё разрешено» в «всё запрещено, кроме явно разрешённого».
Это важно не только для безопасности. Контроль трафика помогает соблюсти границы между средами, разграничить доступ к базам данных и внешним API, а также минимизировать blast radius при компрометации одной из служб. Правильно спроектированные правила упрощают аудит и поддержку сетевой архитектуры.
Базовые понятия и элементы
Network Policy — объект в API Kubernetes, который применяет правила к выбранному набору подов. Важные компоненты: селекторы (podSelector, namespaceSelector), направления (ingress, egress) и, при необходимости, ipBlock для описания внешних подсетей. Политика описывает только то, что разрешено — она не запрещает явно те потоки, которые не перечислены.
Ещё один ключевой момент: сетевые политики выполняются плагином CNI. Если установлен CNI без поддержки этих правил, объекты NetworkPolicy будут бесполезны. Популярные реализации с поддержкой: Calico, Cilium, Kube-router и некоторые другие; у каждого есть свои расширения и особенности поведения.
Поведение по умолчанию простое, но невинно вводящее в заблуждение. Если к поду не применена ни одна политика, весь трафик разрешён. Но если хотя бы одна политика выбирает под, то для соответствующего направления разрешён будет только тот трафик, который явно описан. Это правило критично понимать при деплое первых политик.
Короткая справка по полям
Поле podSelector определяет набор подов, к которым привязана политика. namespaceSelector позволяет ссылаться на другие неймспейсы. Для описания источников и целей используются списки peer-ов, которые могут ссылаться на поды, неймспейсы или IP-блоки.
Поле policyTypes указывает направления работы политики: Ingress, Egress или оба сразу. Если указать egress, а не добавить соответствующий тип, то некоторые реализации могут не применить правила корректно — поэтому всегда явно указывайте типы, которые хотите контролировать.
Как это работает на практике
Представьте под A, к которому применена политика разрешающая ingress только от подов с лейблом app=frontend в том же неймспейсе. Никакие другие источники не получат доступа, даже если они ранее подключались. Это значит, что при добавлении первой политики вы фактически создаёте «фильтр» на вход и/или выход.
Важно: политики не имеют приоритета и не накладываются друг на друга в смысле «первый сработавший». Разрешение суммируется — если любой из применимых правил позволяет соединение, оно разрешено. Отсюда вытекает правило проектирования: делать политики как можно более специфичными и понятными.
Простой пример политики
Ниже — сокращённый пример, который разрешает входящие соединения к подам с лейблом role=db только из неймспейса backend.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-allow-backend
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: backend
ports:
- protocol: TCP
port: 5432
Этот пример иллюстрирует принцип «разрешить только конкретное»: если вы забудете добавить правило для kube-dns или мониторинга, соответствующие запросы будут блокированы — именно поэтому постепенное внедрение важно.
Типичные сценарии использования
Часто политики применяют для сегментации по функционалу: фронтенд может обращаться к бэкенду, бэкенд — к базе, но фронтенд не должен напрямую трогать базу. Также политики полезны для ограничения исходящего трафика: например, разрешить подам обращаться в интернет только через прокси.
Другой сценарий — мультиарендность: в одном кластере содержатся приложения нескольких команд или клиентов. Сети политик можно использовать для изоляции неймспейсов друг от друга, сохраняя при этом общий базовый набор сервисов (например, мониторинга) с аккуратно выставленными правилами доступа.
Таблица: обзор policyTypes
| policyTypes | Назначение |
|---|---|
| Ingress | Контролирует входящий трафик к выбранным подам |
| Egress | Контролирует исходящий трафик от выбранных подов |
Подводные камни и распространённые ошибки
Самая частая ошибка — внедрять политику в бою без проверки зависимостей. Я видел, как в одном кластере после добавления default-deny политики остановился сбор метрик: разработчики не учли, что kube-dns и сборщики метрик нуждаются в доступе к датасорам.
Другой частый промах — использование слишком общих селекторов. Подсети и IP-блоки удобны, но их использование усложняет поддержку. Лейблы удобнее для людей и CI: вы меняете лейбл — политика автоматически подхватывает изменения.
Технические нюансы: политики не влияют на трафик хостовой сети, если под использует hostNetwork, и не регулируют NodePort внутрь нода так, как многие ожидают. Также помните, что поддержка egress появилась не сразу во всех реализациях — уточняйте поведение вашего CNI.
Инструменты и подходы к тестированию
Перед развёртыванием в продакшн проводите тесты в staging: создавайте тестовые поды, отправляйте запросы curl или nc и проверяйте результаты. Можно автоматизировать сценарии: тест-поды в отдельных неймспейсах пробуют подключиться к защищённым сервисам, а CI проверяет, что нужные соединения проходят, а лишние блокируются.
Для отладки полезны средства, которые предоставляет CNI: calicoctl позволяет просмотреть применённые политики и трафик, Cilium имеет свои утилиты для мониторинга. Но базовый набор — это kubectl exec плюс вывод логов приложения и сетевой отладчик в поде.
- Пошаговый тест: создать pod-агрессор и pod-цель, попытаться соединиться; изменить политику и повторить.
- Проверка DNS: убедиться, что kube-dns открыт для подов, которые его используют.
- Логирование и мониторинг: подключить метрики сетевой активности, чтобы видеть аномалии после внесения правил.
Как я внедрял политики: практический опыт
В одном из проектов мы решили начать с запрета всего трафика во входящем направлении для критичных подов. План был поэтапный: сначала в staging, затем для неключевых сервисов в проде, и только потом для баз данных. Первый rollout показал, что мониторинг не собирает данные — пришлось добавить специфичные ingress-правила для exporter-ов и egress-правила для доступа к облачным API.
Я рекомендую внедрять политики мелкими блоками и держать манифесты в Git. Так можно откатить изменения и проследить, кто и зачем вносил корректировки. Ещё одно наблюдение: удобнее поддерживать структуры, когда лейблы стандартизированы, например role=frontend, role=db, team=payments — это уменьшает количество хитрых правил.
Практические рекомендации
Начните с простого: определите критичные сервисы и закройте их в первую очередь. Не пытайтесь охватить весь кластер за одну операцию. Параллельно подготовьте список зависимостей (DNS, мониторинг, прокси) и заранее подготовьте правила для них.
Храните политики как код, покрывайте тестами и документируйте лейблы. Избегайте wildcard-селекторов вроде podSelector: {} — они делают политику бессмысленной. Если нужна гибкость, думайте о namespaceSelector и выделении сервисов в отдельные неймспейсы.
Наконец, используйте возможности CNI: у Calico и Cilium есть расширения сетевой политики, которые упрощают реализацию сложных сценариев, но помните о переносимости и поддержке команды при выборе решения.
Сетевые политики в Kubernetes — мощный инструмент, который приносит реальную безопасность и контроль, если им пользоваться аккуратно. Продумывайте зависимости, тестируйте изменения пошагово и держите правила под версионным контролем. В таком подходе риск ошибок сводится к минимуму, а преимущества в виде ограниченного blast radius и прозрачного контроля трафика становятся заметны уже в первые недели эксплуатации.
