Kubernetes-кластер ломается не на уровне pod’ов, а на уровне доверия к ним

Kubernetes-кластер ломается не на уровне pod’ов, а на уровне доверия к ним

Kubernetes редко падает от одного грубого удара. Чаще атакующий использует слабую связку: открытый API, избыточные права service account, слабую сегментацию сети и доступ к секретам через misconfigured volume или env. Если у злоумышленника есть возможность читать namespace, он уже близко к lateral movement.

Минимальный базис защиты:
— закрытый API-server и ограничение доступа по сети;
— RBAC по принципу least privilege, без cluster-admin для сервисов;
— отдельные namespace для приложений, инфраструктуры и CI/CD;
— NetworkPolicy на вход и выход, иначе pod видит больше, чем должен;
— secrets только через encrypted storage и с ротацией, а не как статичный артефакт в манифесте.

Изнутри кластер обычно атакуют через supply chain и компрометированные workload’ы. Проверяйте admission-контроль, запрещайте privileged containers, hostPath, hostNetwork и запуск от root там, где это не оправдано архитектурно. Отдельно контролируйте доступ CI/CD к kubeconfig: токен, который живёт слишком долго, превращает пайплайн в постоянный канал доступа.

Снаружи критичны не только ingress и WAF, но и поверхность управления: dashboard, metrics, kubelet, etcd, exposed node ports. Проверяйте логи, истина всегда скрыта в них. Если аудит и сетевые политики включены формально, кластер уже считается частично скомпрометированным. Периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.