Нов инструмент за сигурност с отворен код, наречен OperTraitor, разкри как операторите на Kubernetes могат да създадат опасни пътища за ескалация на привилегии, когато получат прекомерни разрешения за управление на достъпа на базата на роли (RBAC).
Инструментът анализира манифестите на операторите и сравнява тяхната документирана функция с разрешенията, които действително са предоставени на техните сервизни акаунти (service accounts).
Операторите на Kubernetes автоматизират административни задачи като внедряване на бази данни, мониторинг на работни натоварвания и управление на инфраструктурни ресурси. Те използват дефиниции на персонализирани ресурси (CRD) и контролери, за да сравняват непрекъснато желаното състояние на клъстера с неговото действително състояние.
За да направят това, операторите се нуждаят от сервизни акаунти в Kubernetes с RBAC разрешения. Въпреки това на много оператори се предоставят широки разрешения за по-голямо удобство.
В някои случаи разработчиците използват разрешения с заместващи знаци (wildcards) или роли на ниво клъстер (ClusterRoles), вместо да ограничат достъпа до пространствата от имена (namespaces) и ресурсите, от които операторът наистина се нуждае.
Ако атакуващ компрометира такъв оператор чрез уязвимо изображение на контейнер, дефект в зависимостите или атака по веригата за доставки, тези разрешения могат да превърнат ограничено пробиване на сигурността в инцидент, засягащ целия клъстер.
Инструментът OperTraitor
OperTraitor, пуснат от Palo Alto Networks, анализира RBAC YAML манифести от локално инсталирани Kubernetes оператори и от каталога OperatorHub.
Той използва механизъм за анализ, базиран на голям езиков модел (LLM), за да идентифицира разликите между заявената цел на оператора и неговите действителни привилегии. След това инструментът определя нормализирана оценка на риска от 1 до 10, помагайки на специалистите по защита да идентифицират оператори, чиито RBAC разрешения може да се наложи да бъдат намалени.
Изследването установи, че повече от 5% от проучените оператори изискват прекомерни разрешения, включително потенциални пътища за достъп до администраторски права над клъстера.
Проблемът е особено тревожен за по-стари или изоставени оператори, които все още са достъпни чрез OperatorHub и Operator Lifecycle Manager.
Въпреки че вендорите могат да публикуват по-нови версии чрез Helm диаграми, GitHub или ArtifactHub, остарелите версии могат да останат достъпни в регистрите по подразбиране и все още да бъдат внедрявани от потребителите.
Един такъв случай включва оператора Prometurbo на IBM, използван с IBM Turbonomic. OperTraitor установи, че операторът разполага с разрешения на ниво клъстер да получава (get), изброява (list) и наблюдава (watch) тайни (Secrets) в Kubernetes.
Това означава, че компрометиран оператор би могъл да получи достъп до чувствителни данни от несвързани пространства от имена, включително токени за сервизни акаунти, идентификационни данни за бази данни, API ключове и TLS сертификати.
IBM отстрани уязвимостта след отговорно разкриване, като за CVE-2026-6389 беше определена висока степен на сериозност CVSS 8.8, и намали разрешенията на оператора, за да спази по-добре принципите за най-малки привилегии.
OperTraitor също така сигнализира за оператора на Datadog поради широк достъп до тайни (Secrets) и RBAC ресурси като ClusterRoles и ClusterRoleBindings.
От Datadog заявиха, че някои разрешения са необходими, тъй като потребителите могат да дефинират имена на тайни динамично, което ги прави трудни за предварително ограничаване. Вендорът публикува документация, обясняваща разрешенията и наличните мерки за смекчаване на риска, което позволява на клиентите да оценят риска.
Констатациите подчертават нарастващите рискове, тъй като Kubernetes внедрява оператори с подобрени LLM възможности и агентни функции, които могат да вземат автономни решения, да извикват външни услуги и да управляват жизнения цикъл на агентите; прекомерните RBAC привилегии могат да изложат на риск чувствителни данни в клъстера или да позволят непредвидени действия в голям мащаб.
Екипите по сигурност трябва да преглеждат сервизния акаунт на всеки оператор, да избягват внедряването на остарели пакети от регистрите и да предпочитат роли на ниво пространство от имена (Roles) пред роли на ниво клъстер (ClusterRoles), където е възможно.
Мониторингът на дневниците за одит (audit logs) в Kubernetes също може да помогне за идентифициране на необичайно поведение, като например опит на оператор да чете тайни от несвързани пространства от имена.
OperTraitor предоставя на екипите по защита начин да откриват рискови нечовешки identities, преди те да се превърнат в път към пълно компрометиране на Kubernetes клъстера.