Безопасность Kubernetes: 12 типичных ошибок, которые мы видим в каждом втором кластере

Что показывает реальная практика аудитов

В 2026 году Kubernetes стал стандартной платформой для размещения корпоративных приложений в большинстве средних и крупных российских ИТ-команд. Параллельно вырос и средний уровень компетенций по эксплуатации, но конфигурационные проблемы остаются нормой, а не исключением. По нашим аудитам за последние два года, из десяти проверенных кластеров примерно в восьми встречаются хотя бы три из приведённых ниже двенадцати ошибок. В половине случаев эти ошибки делают возможной полную компрометацию кластера за пятнадцать-сорок минут с момента получения злоумышленником доступа к одному поду.

Ниже список самых частых проблем, в порядке от наиболее критичных к менее критичным. Для каждой даём способ быстрой проверки и направление исправления.

1. Запуск контейнеров от root без необходимости

Большинство официальных образов в публичных реестрах по умолчанию запускаются от root внутри контейнера. Если ваше приложение реально не требует root-прав, это создаёт ненужный риск. При компрометации контейнера злоумышленник получает root в namespace, и дальше открываются возможности для эскалации, особенно если рядом найдётся уязвимость в kernel.

Быстрая проверка состоит в выполнении команды kubectl get pods --all-namespaces -o jsonpath с фильтром по securityContext. Если у вас в кластере значительная часть подов работает без явного указания runAsNonRoot и runAsUser, проблема существует. Решение это явное задание securityContext с runAsNonRoot true и конкретным runAsUser в манифестах. Pod Security Standards в режиме restricted блокируют такие конфигурации на уровне кластера.

2. Разрешённые привилегированные контейнеры

Контейнер с privileged true фактически имеет доступ ко всем capabilities хоста. Это ровно то же, что запустить процесс на хосте без изоляции. Привилегированные контейнеры нужны для очень узкого круга задач, обычно связанных с обслуживанием самого Kubernetes. В рабочих нагрузках их быть не должно, никогда.

Проверка: kubectl get pods --all-namespaces с поиском securityContext.privileged true. Если такие поды есть в namespace ваших приложений, это критичная находка. Решение это перенос специальных задач в отдельные namespace с строгим контролем доступа, а лучше переписать конфигурацию так, чтобы privileged не требовался вообще. В большинстве случаев это решается явным заданием нужных capabilities вместо общего privileged.

3. Отсутствие сетевых политик

По умолчанию в Kubernetes между подами разрешена любая сетевая коммуникация. Это означает, что любой скомпрометированный под видит все остальные сервисы кластера, включая внутренние API, базы данных, секрет-менеджеры. NetworkPolicy ресурсы позволяют ограничить взаимодействие принципом минимальных привилегий, но они должны быть явно созданы.

Проверка: kubectl get networkpolicy --all-namespaces. Если результат пустой или содержит только пару политик в одном namespace, у вас плоская сеть. Решение это поэтапное внедрение сетевых политик начиная с критических namespace, обычно сначала закрывают входящий трафик к управляющим компонентам, потом изолируют production от staging, потом ограничивают исходящий трафик за пределы кластера.

4. Использование default service account

Каждый namespace имеет default service account, и поды без явного назначения SA получают токен этой учётной записи. Если default SA имеет хоть какие-то права, то любой под в namespace получает их автоматически. Регулярно встречаем ситуацию, когда в default SA по ошибке привязана роль с широкими правами, и десятки подов работают с этими правами без необходимости.

Проверка состоит из двух шагов. Сначала kubectl get rolebinding clusterrolebinding с фильтром по subject.name default. Дальше проверка каких ролей назначены этим биндингам. Решение это явное создание service accounts для каждого приложения с минимально необходимыми правами, и блокировка создания подов с default SA через политики OPA или Kyverno.

5. Хранение секретов в манифестах в открытом виде

Kubernetes Secret по умолчанию хранится в etcd просто в base64. Это не шифрование, это кодирование. Любой человек с доступом к etcd видит ваши пароли в открытом виде. При этом разработчики часто хранят сами манифесты с секретами в git-репозиториях, и сотни глаз могут видеть production-секреты.

Проверка: пройдитесь по своим git-репозиториям с конфигурацией Kubernetes и найдите файлы вида secret.yaml. Если их содержимое можно декодировать через base64 -d и получить рабочий пароль, у вас проблема. Решение это включение шифрования secrets at rest в etcd через EncryptionConfiguration, использование внешних секрет-менеджеров вроде HashiCorp Vault или Yandex Cloud KMS, переход на sealed-secrets или external-secrets операторы, которые позволяют хранить зашифрованные значения в git.

6. Использование :latest тега для production образов

Тег latest означает "последний загруженный", и его содержимое меняется со временем. Это означает, что одна и та же спецификация пода в разные дни может запускать разные версии образа. Помимо проблем со стабильностью, это создаёт риск supply chain атак: если злоумышленник получает доступ к вашему registry или к репозиторию исходного образа, он подменяет latest на изменённую версию, и при следующем развёртывании в кластер заходит вредоносный код.

Проверка: kubectl get pods --all-namespaces с выборкой image и поиск тегов latest или отсутствующих тегов. Решение это требование явного указания версии или digest для production образов, что закрепляется политикой admission control. Использование image digest вида sha256:abcdef... является самой надёжной защитой, потому что digest невозможно подменить незаметно.

7. Слишком широкие RBAC-разрешения

Создание роли cluster-admin для service account это плохая практика, но регулярно встречающаяся. Часто разработчик не разобрался с конкретными permissions и взял максимальные права для скорости. После релиза эта временная конфигурация остаётся навсегда. Любая компрометация контейнера в таком случае даёт полный контроль над кластером.

Проверка: kubectl get clusterrolebinding с поиском cluster-admin в roleRef. Уточните, кому именно эти права нужны. Решение это пересмотр RBAC по принципу минимальных привилегий, обычно через инструменты вроде krane или audit2rbac, которые анализируют реально используемые API-вызовы и предлагают минимальный набор разрешений.

8. Открытые dashboard и kubelet endpoints

Kubernetes Dashboard это удобный инструмент, но в публичной сети это входная точка для злоумышленников. Также kubelet API на портах 10250 и 10255 в небезопасной конфигурации позволяет читать метаданные подов и иногда выполнять команды без аутентификации. Регулярно встречаем кластеры, где эти эндпоинты доступны из публичной сети без аутентификации.

Проверка состоит из nmap-сканирования внешнего адреса control plane на стандартные порты. Если 10250 отвечает без TLS-аутентификации, это критичная находка. Решение это либо полное отключение Dashboard в production, либо его развёртывание за reverse proxy с дополнительной аутентификацией. Для kubelet нужно настроить anonymous-auth false и authorization-mode Webhook, что является базовой защитой.

9. Отсутствие контроля над admission

Без admission controllers любой манифест попадает в кластер при наличии у пользователя соответствующих RBAC-прав. Это означает, что разработчик с правами на создание подов может создать привилегированный под, под с hostPath на /etc/shadow, под с любыми образами из недоверенного registry. Pod Security Standards и инструменты вроде OPA Gatekeeper или Kyverno позволяют запретить создание манифестов, не соответствующих политикам.

Проверка: kubectl get validatingwebhookconfiguration и mutatingwebhookconfiguration. Если у вас нет ни одной политики, проверяющей манифесты на безопасность, у вас нет admission control. Решение это поэтапное внедрение политик, начиная с базовых: запрет privileged подов, запрет hostPath к чувствительным каталогам, запрет образов из недоверенных registries, требование заданного securityContext.

10. Отсутствие аудит-логов или их потеря

Kubernetes audit log это критичный источник для расследования инцидентов. Без него невозможно восстановить, кто создал странный под, кто получил токен service account, какие API-вызовы были сделаны до подозрительной активности. По умолчанию audit log не включён или включён в минимальном режиме. Регулярно видим ситуации, когда после инцидента команда обнаруживает, что логи начинаются за два дня до текущего момента, потому что ротация была настроена слишком агрессивно.

Проверка: запустите kubectl create namespace test-audit-namespace и убедитесь, что это действие отражается в audit log. Если логов нет, либо они хранятся менее тридцати дней, у вас проблема. Решение это включение audit policy в режиме RequestResponse для критичных API-объектов, отправка логов во внешнюю систему хранения, например в SIEM, и настройка retention минимум на девяносто дней.

11. Отсутствие image scanning в пайплайне

Образы в публичных реестрах содержат базовые ОС-пакеты, которые тоже подвержены уязвимостям. Старый образ Alpine с устаревшим OpenSSL это потенциальная дыра, даже если ваше приложение само написано безупречно. Сканирование образов на уязвимости должно быть встроено в CI/CD пайплайн с блокировкой сборок при наличии критичных CVE.

Проверка: посмотрите конфигурацию вашего CI на наличие шага сканирования. Если его нет, либо он только для информации без блокировки, у вас проблема. Решение это внедрение сканера вроде Trivy, Grype или встроенных функций registry в Yandex Cloud, GitLab, Harbor. Сканирование должно происходить и при сборке, и при загрузке в registry, и периодически на уже загруженных образах, потому что новые CVE появляются после публикации.

12. Старые версии Kubernetes и компонентов

Kubernetes выпускает новую минорную версию каждые четыре месяца, и поддерживает каждую версию около двенадцати месяцев. Старые версии не получают обновлений безопасности, и в них регулярно находят уязвимости. По нашим наблюдениям, у значительной доли кластеров средних компаний версия Kubernetes отстаёт от поддерживаемой на одну-две минорные версии, что является прямой проблемой безопасности.

Проверка: kubectl version. Сравните серверную версию с актуальной таблицей поддержки на официальном сайте Kubernetes. Если ваша версия не поддерживается, исправление является приоритетом. Решение это плановое обновление через ноль-простой процедур, обычно через управляемые сервисы Yandex Managed Kubernetes или Cloud.ru. Для self-hosted кластеров используется kubeadm upgrade с поэтапным обновлением узлов.

Что делать сразу после прочтения

Не пытайтесь закрыть все двенадцать пунктов одновременно. На практике это превращается в большой проект с потерей фокуса. Эффективнее работать по приоритету. В первую неделю проверьте пункты с первого по пятый, потому что это критичные конфигурационные проблемы с быстрым исправлением. В течение месяца разберитесь с пунктами шесть-девять, что требует изменений в процессах CI/CD и admission control. В течение квартала закройте пункты десять-двенадцать, что является более системной работой.

Если у вас нет ресурса, чтобы заниматься этим самостоятельно, имеет смысл заказать аудит безопасности Kubernetes у внешней команды. Профильный аудит обычно занимает от недели до трёх в зависимости от размера кластера, и стоит ориентировочно от пятисот тысяч до двух миллионов рублей в условиях 2026 года. По итогам вы получаете не только список проблем, но и понятную дорожную карту с приоритизацией.

Безопасность Kubernetes это не разовая работа, а постоянный процесс. Появляются новые версии, новые угрозы, новые best practices. Регулярная проверка по чек-листу должна быть встроена в операционную деятельность DevOps-команды.

Связанные материалы

Если вам нужно глубже разобраться с темами из этой статьи, начните с следующих ресурсов. Официальный документ CIS Benchmark for Kubernetes содержит детальный набор проверок и команд. NSA-CISA Kubernetes Hardening Guide описывает рекомендации с государственного уровня. Документация по Pod Security Standards в Kubernetes покрывает практическое внедрение профилей безопасности. Статья про Network Policies в нашей экспертизе скоро тоже появится.

Если вам нужна помощь с практическим внедрением чего-то из перечисленного, напишите нам. Готовы провести бесплатный экспресс-аудит, на котором покажем конкретные находки в вашем кластере и приоритеты для устранения.