Как ограничить общение приложений в разных неймспейсах

Ограничение общения между приложениями в разных namespace Kubernetes

В Kubernetes namespace являются механизмом для логического разделения кластера и изоляции ресурсов. Для ограничения общения между приложениями в разных namespace используется сочетание политик сети (Network Policies) и сервисов. Основной инструмент — NetworkPolicy, который определяет правила для трафика между Pods.

Основные принципы ограничения трафика

1. Использование NetworkPolicy

NetworkPolicy позволяет контролировать входящий (ingress) и исходящий (egress) трафик Pods на основе меток, namespace и IP-адресов. Для работы NetworkPolicy требуется сетевой плагин CNI, поддерживающий эту функциональность (например, Calico, Cilium).

Пример NetworkPolicy, полностью блокирующий трафик между namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace-traffic
  namespace: app-namespace
spec:
  podSelector: {} # Применяется ко всем Pods в namespace
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector: {} # Только трафик от Pods внутри этого же namespace
  egress:
  - to:
    - podSelector: {} # Только трафик к Pods внутри этого же namespace

2. Селекторы namespace в NetworkPolicy

Для более гибкого управления можно указывать конкретные namespace:

spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: trusted-namespace # Только из namespace с меткой name=trusted-namespace

3. Блокировка всех входящих/исходящих подключений

Если необходимо полностью изолировать namespace, применяется политика "default deny":

# Политика "default deny all" для ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: isolated-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: [] # Пустой список = запрет всего входящего трафика

Практические шаги реализации

1. Анализ требований: Определить, какие приложения должны общаться и по каким портам.
2. Разметка namespace: Добавить метки к namespace для использования в namespaceSelector.

   kubectl label namespace production type=prod
   

3. Создание базовых политик: Начать с политик "default deny", затем добавлять разрешающие правила.
4. Тестирование: Проверить доступность сервисов с помощью временных Pods или инструментов (curl внутри кластера).

Альтернативные и дополнительные подходы

• Сетевые плагины с расширенными функциями: Cilium поддерживает политики на уровне L7 (HTTP, gRPC) и интеграцию с сервис-мезами.
• Service Mesh (Istio, Linkerd): Предоставляет более тонкий контроль трафика, включая межnamespace коммуникацию, с возможностями TLS, мониторинга и управления доступом на уровне приложений.
• DNS и Service объекты: Сервисы Kubernetes по умолчанию доступны из всех namespace. Для ограничения можно использовать внешние DNS политики или настроить внутренние DNS-серверы (CoreDNS) на фильтрацию запросов.

Пример комплексной политики

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-to-db-policy
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: database-namespace
      podSelector:
        matchLabels:
          role: mysql
    ports:
    - protocol: TCP
      port: 3306

Эта политика разрешает Pods с меткой app=backend в namespace app соединяться только с Pods role=mysql в namespace с меткой name=database-namespace на порт 3306.

Заключение

Ограничение общения между namespace — критически важная часть безопасности Kubernetes-кластера. Начинать следует с NetworkPolicy, понимая, что их эффективность зависит от сетевого плагина CNI. Для сложных сценариев рассматривайте Service Mesh и дополнительные возможности вашего CNI-плагина. Регулярно аудитируйте политики и тестируйте их в условиях, приближенных к производственным.