Kubernetes ломают не только снаружи: чаще всего атака приходит изнутри

Kubernetes ломают не только снаружи: чаще всего атака приходит изнутри

Периметр кластера иллюзорен. Вход через ingress, компрометированный CI/CD, лишний kubeconfig у разработчика или сервисный аккаунт с широкими правами дают атакующему тот же эффект, что и прямой доступ к control plane. Дальше обычно идут:
— чтение секретов из namespace;
— подмена образов и манифестов;
— закрепление через CronJob, DaemonSet или admission-обход;
— lateral movement к базе, очередям и хранилищам.

Снаружи картина не лучше: открытый API-server, слабая сегментация сети, доступ к kubelet, неограниченные NodePort и отсутствие network policy превращают кластер в плоскую среду. При таком дизайне один скомпрометированный pod быстро получает видимость соседних сервисов. Проверяйте логи, истина всегда скрыта в них.

Минимальный набор контроля: RBAC по принципу least privilege, отдельные роли для человека и workload, запрет wildcard-прав на secrets и pods/exec, обязательная ротация токенов, audit-log на все чувствительные запросы. Для сети — default deny, явные allow-листы между namespace, закрытый control plane и ограничение egress, чтобы утечка не уходила без шумовых сигналов.

Не менее важен supply chain: подписанные образы, запрет запуска privileged-контейнеров, контроль admission policy, запрет hostPath и hostNetwork без исключений, а также сканирование манифестов до деплоя. Периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.

Если в кластере можно прочитать секрет, выполнить exec и отправить трафик наружу без ограничений, защита уже частично проиграна. Начинайте с изоляции прав, затем сжимайте сетевой радиус поражения.