Kubernetes защищают не “по периметру”: ошибки в RBAC и сетях открывают кластер изнутри

Kubernetes защищают не “по периметру”: ошибки в RBAC и сетях открывают кластер изнутри

Kubernetes обычно ломают двумя путями: внешний доступ к API и дальнейшая эскалация внутри кластера. Поэтому базовая схема защиты строится не на одном барьере, а на разделении доверия: API-server не должен быть доступен всем подряд, а каждый namespace — жить как отдельная зона риска.

Контролируйте следующие точки:
— RBAC: минимальные права для service account, запрет wildcard-ролей и cluster-admin по умолчанию.
— NetworkPolicy: разрешайте только нужные потоки между pod’ами, а не “всё внутри кластера”.
— Secrets: не храните их в env без необходимости, ограничьте чтение и ротацию.
— Admission control: отклоняйте privileged, hostNetwork, hostPath и запуск без securityContext.
— Audit log: фиксируйте, кто создал pod, изменил роль или запросил secret.

Для атак изнутри критичны компрометация pod’а и кража токена service account. Если pod имеет доступ к metadata, kubelet API или лишним volume mount’ам, злоумышленник быстро переходит от одной рабочей нагрузки к соседним. Отсюда правило: один workload — один набор прав, один маршрут сети, один контур наблюдения.

Снаружи основной риск — открытый API, слабая аутентификация и незащищённые dashboard/ingress-панели. Закрывайте управляющие интерфейсы за VPN или bastion, включайте mTLS там, где это возможно, и не доверяйте ingress как единственной точке фильтрации: он видит трафик, но не отменяет уязвимую логику приложения.

Проверяйте логи, истина всегда скрыта в них. Если в кластере есть хотя бы один pod с лишними правами, защиту нужно считать неполной: периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.