Kubernetes защищают не «периметром», а контролем каждого допуска в кластер

Kubernetes защищают не «периметром», а контролем каждого допуска в кластер

Внешняя атака почти всегда начинается с чрезмерных прав: открытый API-server, доступные kubelet, слабые токены service account, отсутствие сегментации между ingress и control plane. Минимум, который должен быть закрыт по умолчанию: RBAC по принципу least privilege, ограничение доступа к API через сеть, включенный audit-log и запрет anonymous-auth.

Внутренний риск обычно опаснее: компрометация одного pod превращается в движение по namespace и дальше по кластерам. Для снижения радиуса поражения используйте Pod Security Standards, network policy между workload’ами, отдельные service account на каждый сервис и отказ от privileged/hostPath без жесткой необходимости. Если контейнеру нужен root, это повод пересмотреть архитектуру, а не расширять исключение.

Отдельно контролируйте секреты: не храните их в env без необходимости, используйте внешнее хранилище секретов, ротацию и короткоживущие токены. Любой CI/CD-раннер, имеющий права deploy, должен рассматриваться как часть доверенной зоны; его компрометация равна получению прав на кластер. Проверяйте права admission-controller’ов, webhook’ов и образов из registry — именно там часто остаются незаметные точки внедрения 🔒

Базовая модель проста: ограничить сеть, урезать права, изолировать workload’ы, логировать все критичные действия. Периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.