Network Policy and Pod Security

Две двери default-allow: сеть и спека пода

У безопасности Kubernetes повторяющаяся форма: платформа поставляется в режиме default-allow, а безопасность — это то, что ты добавляешь. Две такие двери — тема этого урока, и они независимы: закрытие одной ничего не делает для другой.

Дверь первая — плоская сеть. Сетевая модель Kubernetes требует, чтобы каждый под мог достать любой другой под по IP, через все неймспейсы, без NAT. Это не баг; это контракт, который обязан выполнять CNI-плагин. Следствие: east-west-трафик (под-под) по умолчанию полностью открыт. NetworkPolicy — это opt-in объект, который его ограничивает, но только если твой CNI реализует enforcement NetworkPolicy (Calico, Cilium и большинство managed-CNI это делают; легаси-дефолт flannel — нет, так что политика, которую ты kubectl apply, успешно применяется и тихо не enforce-ит ничего).

Дверь вторая — SecurityContext пода. Контейнер без securityContext работает под тем UID, который задаёт образ — часто root (UID 0) — наследует дефолтный набор Linux-capabilities, может получить privileged: true, монтировать тома hostPath и делить с хостом namespace PID или сети. Каждое из этого — задокументированный примитив побега из контейнера. Pod Security Standards (PSS) определяют три профиля — privileged (без ограничений), baseline (блокировать известные побеги) и restricted (жёстко закрыт: non-root, без добавленных capabilities, seccomp включён) — а Pod Security Admission (PSA) — это встроенный admission-контроллер, enforce-ящий выбранный профиль для неймспейса через метки.

NetworkPolicy: аддитивный allow и паттерн default-deny

NetworkPolicy только разрешающая и аддитивная, ровно как RBAC — deny-правила нет. Трюк, заставляющий её вести себя как файрвол, — это селектор: в момент, когда любая NetworkPolicy выбирает под для заданного направления (ingress или egress), этот под перещёлкивается с default-allow на default-deny для этого направления, и пропускается только тот трафик, что явно перечислен в любой выбирающей его политике. Объединение всех совпавших политик — это allow-список.

Поэтому каноничный приём хардненинга — это default-deny на неймспейс: политика, что выбирает каждый под, но не перечисляет разрешённых соседей:

Неочевидный режим отказа живёт во второй строке. В тот миг, когда ты применяешь default-deny egress-политику, ты заодно блокируешь DNS-запросы пода к kube-dns, потому что это egress к другому поду на порт 53. Каждый запрос тогда падает не с «connection refused», а с ошибкой резолва имени, что отправляет инженеров отлаживать не тот слой на час. Корректный default-deny поэтому всегда пара: deny-all плюс явное allow-DNS egress-правило. Это самая частая причина, по которой команды откатывают NetworkPolicy и объявляют её «слишком сложной».

Pod Security Standards: блокировать побег, а не только сеть

NetworkPolicy сдерживает латеральное движение между подами. Она ничего не делает с подом, который сбегает вниз к ноде — а это разрешает неограниченный SecurityContext. Три побега, что важны, и что делает с каждым профиль restricted:

1. Работа под root. runAsNonRoot: true плюс ненулевой runAsUser означает, что побег из контейнера высаживает атакующего под непривилегированным UID, а не root, резко ограничивая, что он может на ноде, если вырвется из namespace.
2. privileged: true и добавленные capabilities. У privileged-контейнера по сути все capabilities и доступ к устройствам — это почти прямой путь к хосту. restricted запрещает privileged, требует сбросить ALL capabilities и возвращает обратно только NET_BIND_SERVICE.
3. Host-namespaces и hostPath. hostPID: true / hostNetwork: true делят процессный или сетевой вид ноды; том hostPath может примонтировать / и прочитать креды kubelet. restricted и baseline оба это блокируют.

Pod Security Admission enforce-ит профиль по метке неймспейса, в трёх режимах — enforce (отклонять несоответствующие поды), audit (логировать их) и warn (предупреждать применяющего) — так что можно выкатить сперва в warn/audit и посмотреть, что сломалось бы, перед переключением на enforce: