Налаштування 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 в Kubernetes

kubelet виконує health-перевірки в Kubernetes з 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. Середній час налагодження однієї політики — 30 хвилин.

Порівняння CNI-плагінів для Network Policies

Cilium у 2-3 рази швидший за Calico при фільтрації на рівні L7 завдяки eBPF. Cilium забезпечує в 2 рази кращу спостережуваність, ніж Calico, завдяки Hubble. Для більшості продакшн-сценаріїв 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).

Вартість типового проекту визначається після аналізу складності та кількості сервісів.

Строки виконання

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

Наш досвід — 5+ років та 40+ проєктів — гарантія якісного налаштування Network Policies. Усі роботи виконують сертифіковані інженери. Зверніться до наших інженерів для аудиту вашого кластера — розрахуємо строки та обсяг робіт під ваш проект. Замовте впровадження Network Policies під ключ: забезпечимо безпеку без простоїв.

Джерело: Kubernetes Documentation