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

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

Внешняя атака обычно начинается не с brute force, а с утечки kubeconfig, токена CI/CD или открытого API-сервера без ограничений по source IP. Если у злоумышленника есть доступ к control plane, дальше работают привычные техники: перебор ServiceAccount, чтение Secrets, злоупотребление RBAC и запуск подов с лишними правами.

Внутренний риск почти всегда связан с избыточными привилегиями. Проверьте: • нет ли cluster-admin у сервисных аккаунтов по умолчанию; • запрещён ли запуск privileged-подов и hostPath без явного допуска; • включён ли admission control для политик безопасности; • ограничены ли возможности exec, port-forward и создание новых токенов. Минимизация прав должна начинаться не с приложений, а с namespace-границ и ролей.

Сетевой периметр внутри кластера не должен быть плоским. NetworkPolicy должна закрывать east-west трафик по принципу deny by default, а доступ к etcd, метрикам, ingress-controller и секретам — быть сегментирован. Отдельно контролируйте образа контейнеров: подпись, контроль реестра, запрет запуска образов из непроверенных источников и сканирование на уязвимости до деплоя.

Логи API-server, audit-log, события namespace и изменения RBAC — это основной источник раннего обнаружения. Проверяйте логи, истина всегда скрыта в них. Если в кластере нельзя быстро ответить, кто выдал права, кто создал pod и откуда пришёл запрос, значит защита построена формально. Периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.