Специалисты Unit 42 (Palo Alto Networks) опубликовали исследование об операторах Kubernetes — программных методах автоматизации, которые расширяют API Kubernetes с помощью пользовательских ресурсов для полного управления жизненным циклом приложения. Проверив экосистему, исследователи выяснили, что чуть более 5% операторов запрашивают избыточные права, включая скрытые пути к правам администратора кластера. К исследованию Unit 42 приложили открытый инструмент OperTraitor, который автоматически сверяет выданные оператору права с тем, что ему положено по документации, и присваивает оценку риска.
Чем опасны права операторов
Операторы Kubernetes давно стали привычным способом развертывания и сопровождения инфраструктуры сложных приложений вроде баз данных или систем мониторинга. Они избавляют инженеров от рутинных задач, но при этом создают огромную слепую зону для информационной безопасности.
Суть проблемы в том, как оператору выдаются права. Чтобы обновлять приложения, делать бэкапы или перезапускать поды, ему нужны полномочия в RBAC (Role-based access control) — системе распределения прав доступа к различным объектам в кластере. Исследование Unit 42 показало, что разработчики часто идут по пути наименьшего сопротивления — вместо точечной настройки прав они запрашивают глобальную роль ClusterRole и доступ к секретам по всему кластеру.
При взломе оператор отдает злоумышленнику все права своего сервисного аккаунта. Попасть внутрь можно разными путями: через уязвимость в зависимостях, атаку на цепочку поставок или захват узла, но масштаб последствий в любом случае диктуют выданные права.
Практические кейсы
Кейс с CVE-2026-6389 в IBM Turbonomic с серьезностью CVSS 8.8/10 иллюстрирует, как это выглядит на практике. Сервисный аккаунт оператора Prometurbo был привязан к ClusterRole, которая давала права чтения секретов во всем кластере, хотя оператору требовался доступ только к собственному неймспейсу. В случае компрометации это означало бы доступ атакующего к административным токенам, паролям баз данных и TLS-сертификатам из посторонних неймспейсов, то есть к значительной части среды. IBM отреагировала на отчет исследователей, ограничив права оператора и опубликовав бюллетень безопасности.
Это не единичный случай — аналогичные избыточные права были найдены и у других операторов. Каталог Operator Hub заполнен заброшенными компонентами с избыточными правами — новые защищенные версии вендоры публикуют только через Helm-чарты, собственные репозитории GitHub или ArtifactHub, а устаревшие остаются доступными через Operator Lifecycle Manager (OLM). В результате пользователи регулярно разворачивают устаревшие операторы, часто не осознавая этого.
Второй кейс касался оператора Datadog с избыточной, по оценке OperTraitor, конфигурацией — доступом к секретам всего кластера и действиями над RBAC-ресурсами. Представители компании объяснили, что имена секретов формируются из пользовательских значений и не могут быть известны до развертывания. Исследователи признали этот аргумент валидным — он иллюстрирует сложный компромисс вендоров между строгой безопасностью и удобством установки. Вместо сокращения прав Datadog опубликовала подробное описание своих настроек и применяемые меры защиты, чтобы ИБ-специалисты могли осознанно принять решение, оценив все риски.
Агентные операторы
Отдельное внимание стоит уделить тому, что произойдет с этой проблемой в будущем. Индустрия постепенно переходит к агентным операторам — автономным системам, которые управляют кластером с помощью LLM и ИИ-рассуждений. Выделяют три таких паттерна: операторы с ИИ-логикой вроде K8sGPT, операторы-«мосты», через которые внешние ИИ-агенты получают доступ к кластеру, и операторы, управляющие жизненным циклом ИИ-агентов внутри кластера. Во всех трех случаях избыточные права, которые сегодня выглядят просто ошибкой в настройке, в руках автономной системы превращаются в активный вектор угрозы.
Вывод
Широкие полномочия операторов Kubernetes требуют такого же системного контроля, какой применяется к учетным записям живых администраторов. Инструменты автоматизации в cloud-native среде часто получают больше доверия, чем на самом деле требуется для их задач. Чтобы минимизировать риски, командам стоит устанавливать операторы только из поддерживаемых источников вендора, ограничивать их собственным неймспейсом и регулярно проводить аудит сервисных аккаунтов с профильными сканерами вроде OperTraitor, отслеживая поведение операторов по аудит-логам кластера.
При этом часть работы можно переложить на платформу. В Managed Kubernetes Selectel провайдер отвечает за обновление и безопасность Control Plane, операционной системы, платформы виртуализации и оркестрации, а также за сетевую безопасность служебной инфраструктуры и оборудования в собственных дата-центрах. А команда занимается тем, что действительно требует ее внимания: управлением правами доступа, безопасностью приложения и данных.
Источник: habr.com