Network Policies в Kubernetes: изоляция трафика

Мы просто и по делу рассказываем про ИИ-инструменты для работы: сравнения, пошаговые гайды, бесплатные альтернативы и реальные сценарии применения. Помогаем выбрать между ChatGPT, Gemini, Claude, локальными моделями и десятками узкоспециализированных сервисов — от дизайна и HR до аналитики и SEO. Меньше хайпа, больше практики и экономии времени каждый день.

kubernetesnetworkpolicycni

По умолчанию сеть в Kubernetes часто работает по принципу “все со всеми могут общаться”. Это удобно для старта, но опасно для продакшена: компрометация одного pod может открыть путь к базам, внутренним API и служебным сервисам.

Именно для этого нужны Network Policies — правила, которые ограничивают входящий и исходящий трафик между pod’ами.

Что такое NetworkPolicy

Это Kubernetes-ресурс, который задаёт, кто и куда может передавать трафик на уровне pod.

Политики работают по меткам (labels) и позволяют:

  • ограничить доступ к приложению только нужным сервисам
  • запретить исходящий трафик во внешний мир
  • сегментировать namespace’ы
  • снизить радиус атаки при взломе

Как это работает

Политика выбирает целевые pod через podSelector, а затем описывает:

  • Ingress — кто может подключаться к pod
  • Egress — куда pod может обращаться

Важно: NetworkPolicy начнёт работать только если её поддерживает CNI-плагин. Обычно это Calico, Cilium, Weave Net и другие. Без поддержки плагина манифест применится, но эффекта не будет ⚠️

Базовый принцип безопасности

Хорошая практика — default deny:

  • запретить весь входящий трафик
  • отдельно разрешить только нужные соединения
  • при необходимости так же ограничить исходящий трафик
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Теперь ни один pod в namespace не принимает входящие соединения, пока вы явно их не разрешите.

Пример разрешения доступа

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Что часто забывают

  • DNS: если ограничить egress, приложения могут перестать резолвить имена 🌐
  • мониторинг и логирование: Prometheus, Fluent Bit, агенты безопасности тоже требуют доступ
  • межnamespace-взаимодействие: для него нужен namespaceSelector
  • политики суммируются, а не перезаписываются

Когда Network Policies особенно нужны

  • микросервисная архитектура
  • multi-tenant кластеры
  • production с доступом к БД и внутренним API
  • соответствие требованиям безопасности и аудита 🛡️

Вывод

Network Policies — это не “дополнительная опция”, а базовый уровень защиты Kubernetes. Начинайте с default deny, затем открывайте только необходимое. Такой подход делает сеть кластера предсказуемой, безопасной и управляемой 🚀

👀 Ниже — мягкая рекомендация: загляните в подборку каналов про IT, где регулярно публикуют практику по Kubernetes, DevOps, backend и инфраструктуре.

🗣 Подборки каналов
🧠 Каталог ботов и приложений
🗺 Навигация

Читайте так же