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

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

Основные векторы обычно банальны: снаружи бьют по API-server, Ingress, supply chain образов и открытым kubeconfig; изнутри — по чрезмерным RBAC, доступу к secrets, lateral movement между namespace и компрометации service account token. Если у атакующего есть хотя бы один рабочий токен, дальше вопрос не в «взломе», а в масштабе доступов.

Минимальный базовый набор:
— закрытый API-server и доступ только через VPN/прокси с mTLS;
— отдельные namespace под домены доверия, без shared-сервисов «на всех»;
— RBAC по принципу наименьших привилегий, без cluster-admin для автоматизации;
— NetworkPolicy по умолчанию deny all, затем точечные разрешения;
— secrets не в манифестах, а в защищённом хранилище и с ротацией.

Отдельно проверьте цепочку поставки: подпись образов, сканирование на этапе CI, запрет запуска privileged-контейнеров, hostPath и hostNetwork без явного исключения. Admission policy должна отклонять манифесты, которые ломают границы изоляции. Если контроллеры могут создавать всё подряд, атакующий использует не уязвимость, а вашу автоматизацию.

Соберите наблюдаемость вокруг auth-логов, audit log, событий создания RoleBinding, Secret и новых ServiceAccount. Проверяйте логи, истина всегда скрыта в них. Безопасность — это не состояние, а непрерывный процесс мониторинга и патчинга.