Эта политика применяется к подам с лейблом app: backend и разрешает входящий трафик на порт 8080 только от подов с лейблом app: frontend в рамках того же неймспейса.
Если вам нужно разрешить доступ из подов, находящихся в другом неймспейсе (например, сбор метрик Прометеусом), мы комбинируем селекторы:
ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring podSelector: matchLabels: app: prometheus
Обратите внимание на синтаксис: когда podSelector и namespaceSelector находятся внутри одного элемента списка (как выше), они работают по логике И (под с лейблом prometheus *внутри* неймспейса monitoring). Если бы они начинались с разных дефисов (`-`) - это была бы логика ИЛИ.
Практический план внедрения в продакшен 1. Проверить CNI: убедитесь, что ваш сетевой плагин (Calico, Cilium, Antrea) физически умеет обрабатывать NetworkPolicy. 2. Начните с тестового контура: не раскатывайте default-deny-all сразу на весь продакшен кластер. Выберите один некритичный неймспейс. 3. Включите логирование (если позволяет CNI): Cilium и Calico умеют логировать отброшенные пакеты (dropped packets). Это поможет увидеть, какой легитимный трафик вы случайно заблокировали. 4. Внедрите deny-all и DNS: изолируйте неймспейс и сразу дайте доступ к порту 53 CoreDNS. 5. Опишите явные взаимосвязи: переведите архитектуру приложения в YAML-манифесты политик. 6. Протестируйте доступность: используйте kubectl exec для финальной проверки:
kubectl exec -it <pod-frontend> -n production -- curl http://backend:8080
Важные правила на заметку: 🔹 Если к поду применяется несколько NetworkPolicy, разрешённым считается объединение (*Union*) всех правил. Вы не можете одной политикой «перекрыть» или запретить то, что уже разрешено другой. 🔹 Если вы включили default-deny-all для всего неймспейса, то для успешного соединения под-источник должен иметь разрешение на egress (исходящий трафик), а под-получатель - на ingress (входящий трафик). 🔹 Обратите внимание, это справедливо в рамках одного namespace. Если у вас открыт доступ в соседний неймспейс, а там нет сетевых политик, то доступ будет разрешён. 🔹 Для удобства запоминания: внутри kubernetes доступ чаще всего открывается парно egress/ingress, а вот наружу открывается только egress правило.
Чтобы освоить сетевую безопасность в Kubernetes на практике, включая тонкости работы с CNI, Network Policies, Service Mesh и концепцией Zero-Trust, 🔥открывай демодоступы бесплатно🔥 и прокачивай навыки: * Kubernetes Admin - администрирование кластера, сеть, безопасность, политики. * Networks Basics - основы сетей, CNI, маршрутизация трафика внутри K8s. * Container Security - безопасность контейнеризации, изоляция сред, политики доступа.