Kubernetes ломают не через „магический эксплойт“, а через слабые границы доступа

Kubernetes ломают не через „магический эксплойт“, а через слабые границы доступа

Кластер обычно атакуют с двух сторон: снаружи — через открытый API, ingress, секреты в CI/CD; изнутри — через переиспользованный ServiceAccount, лишние RBAC-права и доступ к metadata service. Если у пода есть возможность эскалировать привилегии, компрометация одного микросервиса быстро превращается в компрометацию всего кластера.

Базовая защита начинается с минимизации поверхности:
— API server не должен быть доступен шире, чем нужно;
— RBAC строится по принципу deny by default;
— ServiceAccount настраивается отдельно для каждого workload;
— секреты не хранятся в манифестах и не попадают в логи;
— admission policy блокирует privileged, hostPath и контейнеры с избыточными capabilities.

Отдельно контролируйте сетевой периметр внутри кластера. NetworkPolicy должна ограничивать east-west трафик между namespace и сервисами, а egress — запрещать неконтролируемые выходы наружу. Для атакующего это критично: даже после закрепления в поде ему нужно двигаться дальше, а сегментация ломает эту траекторию. Параллельно включайте audit logs, мониторинг аномальных exec в контейнеры и алерты на создание новых ClusterRoleBinding.

Для защиты от компрометации изнутри полезны короткоживущие токены, ротация секретов, image signing и запрет запуска неподписанных образов. Любой доступ к kubeconfig, registry и CI должен считаться привилегией, а не удобством. Проверяйте логи, истина всегда скрыта в них.