Kubernetes ломают не только снаружи: внутренняя плоскость доступа опаснее

Kubernetes ломают не только снаружи: внутренняя плоскость доступа опаснее

Контрольный контур кластера должен исходить из принципа минимальных привилегий. Если сервисный аккаунт может читать Secrets, а pod получает лишние capabilities, компрометация одного контейнера быстро превращается в доступ к namespace, а затем и к control plane. Отдельно проверяйте admission policy: без запрета privileged, hostPath и широких RBAC-ролей кластер сам создаёт путь для эскалации.

Снаружи чаще бьют через открытый API-server, Ingress и слабую сегментацию сети. Закрывайте API только для доверенных диапазонов, включайте mTLS между сервисами, ограничивайте egress, чтобы заражённый pod не мог ходить куда угодно. NetworkPolicy должна быть дефолтно запрещающей, иначе микросегментация остаётся декларацией.

Изнутри атака часто начинается с утекших kubeconfig, токенов CI/CD и чрезмерно широких прав у операторов. Разделяйте права на чтение, деплой и администрирование, отключайте бессрочные токены, а доступ к секретам отдавайте через внешнее хранилище с аудитом запросов. Проверяйте, какие service account реально используются, а какие лежат в манифестах по инерции.

Логи audit, событий и admission-контроля должны собираться централизованно: без них инцидент в Kubernetes выглядит как набор разрозненных отказов. Периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.