Kubernetes защищают не “по периметру”, а на каждом уровне доверия

Kubernetes защищают не “по периметру”, а на каждом уровне доверия

В кластере атакуют не только через API-сервер. Векторов достаточно: украденный kubeconfig, избыточные RBAC-роли, подмена образа, доступ к metadata, компрометация pod-to-pod трафика. Если один workload видит больше, чем ему нужно, инцидент быстро становится кластерным.

Минимальный базис:
— запрет на privileged и hostPath без явного исключения;
— RBAC по принципу наименьших привилегий, отдельно для людей и сервис-аккаунтов;
— admission-контроль для образов, namespace policy и запрет небезопасных capabilities;
— сетевые политики между namespace, а не только на границе кластера.

Внутренняя защита начинается с изоляции. Сервис-аккаунт не должен иметь права на чтение Secrets вне своего контура, а pod — на обращение к API без необходимости. Включайте audit log, ограничивайте доступ к etcd, шифруйте Secret на уровне хранилища и проверяйте, кто может создавать CronJob, DaemonSet и ephemeral containers.

Снаружи контролируйте только то, что действительно нужно экспонировать: Ingress, API endpoint, registry, CI/CD-агенты. Весь остальной трафик должен упираться в сегментацию, mTLS и rate limiting. Без этих слоев Kubernetes превращается в удобную среду для lateral movement.

Проверяйте логи, истина всегда скрыта в них. Если в кластере можно поднять pod, прочитать Secret и выйти в сеть без ограничений, защита формальна. Безопасность — это не состояние, а непрерывный процесс мониторинга и патчинга.