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

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

Кластер редко компрометируют «в лоб». Типовые векторы: украденный kubeconfig, избыточные права service account, открытый API-server, слабая сегментация между namespace и отсутствие контроля egress. Если атакующий уже получил foothold в одном pod, он ищет токены, метаданные, секреты в env и доступ к control plane.

Минимальный набор защиты:
— включить RBAC по принципу least privilege;
— запретить automountServiceAccountToken там, где он не нужен;
— изолировать namespace сетевыми политиками;
— закрыть доступ к API-server только из доверенных подсетей;
— выносить секреты в external secrets manager, а не в манифесты и env.

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

Инцидент в Kubernetes почти всегда развивается каскадом: один pod, затем сервис-аккаунт, затем секреты, затем lateral movement. Проверяйте логи, истина всегда скрыта в них.