Сообщить об ошибкеКороткий ответ
NetworkPolicy описывает разрешённый входящий и/или исходящий трафик для подов по селектору меток, namespace и портам; но сам по себе объект NetworkPolicy ничего не делает, если сетевой плагин (CNI) кластера не реализует его поддержку — в этом случае правила принимаются API сервером, но фактически игнорируются, создавая ложное чувство защищённости.
Как это работает подробнее
по умолчанию в Kubernetes весь трафик между подами разрешён; как только к поду применяется хотя бы одна NetworkPolicy с типом Ingress, для этого пода начинает действовать модель "запрещено всё, что не разрешено явно" только для входящего трафика (аналогично для Egress). Правила могут ссылаться на podSelector, namespaceSelector и ipBlock, комбинируя их для точечного разрешения.
Пример кода
manifest.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-frontend-to-backend, namespace: prod }
spec:
podSelector: { matchLabels: { app: backend } }
policyTypes: ["Ingress"]
ingress:
- from:
- podSelector: { matchLabels: { app: frontend } }
ports: [{ port: 8080 }]Что использовать на практике
- Практика. для реализации "default deny" в namespace сначала создают пустую политику, блокирующую весь трафик, а затем — отдельные политики, явно разрешающие нужные соединения (например, только от frontend к backend на конкретном порту). Поддержка NetworkPolicy зависит от CNI: Calico, Cilium и некоторые другие её реализуют, тогда как часть простых плагинов (например, базовый flannel в режиме vxlan без Calico) — нет.
Подводные камни
- Риски. внедрять NetworkPolicy на кластере с CNI, который её не поддерживает, и считать систему защищённой, хотя трафик по факту ничем не ограничен — это нужно проверять документацией конкретного CNI заранее; забывать, что добавление Ingress-политики не блокирует Egress automatически, и наоборот — для полной изоляции нужно управлять обоими направлениями.