Один Kubernetes YAML может отдать всю организацию GCP: confused deputy в Config Connector

Специалисты по кибербезопасности из компании Varonis раскрыли схему атаки, при которой пользователь Kubernetes с минимальными привилегиями способен захватить контроль над всей организацией Google Cloud Platform (GCP). В основе проблемы — классический confused deputy problem, при котором сервис с высокими правами доступа действует от имени менее привилегированного пользователя, не проверяя должным образом его полномочия. Речь идёт о Google Kubernetes Config Connector — официальном инструменте, позволяющем управлять ресурсами GCP напрямую через манифесты Kubernetes. Config Connector работает внутри кластера под сервисным аккаунтом Google Cloud с широкими правами и по сути выступает «доверенным посредником»: он принимает объявления из YAML-файлов и выполняет соответствующие операции в GCP — создаёт проекты, изменяет IAM-политики, управляет сервисными аккаунтами и другими ресурсами организации.

Подробности

Проблема заключается в разграничении доступа. Пользователь, имеющий право создавать или изменять объекты Config Connector в кластере Kubernetes, но не обладающий соответствующими полномочиями в самом GCP, может через манифест «попросить» Config Connector выполнить действия от имени его высокопривилегированного сервисного аккаунта. Поскольку Config Connector не сопоставляет права автора манифеста с правами в GCP, а просто выполняет запрошенные операции, злоумышленник получает возможность эскалации привилегий в обход обычных проверок. Как отмечают исследователи, для эксплуатации достаточно одного YAML-файла. Например, через манифест можно попытаться изменить привязки IAM, выдать себе роль с расширенными правами или создать новый проект и сервисный аккаунт в организации. Если сервисный аккаунт Config Connector наделён правами уровня организации, цепочка приводит к полному контролю над ней. Varonis описывает это как confused deputy problem: Kubernetes-кластер и его пользователи выступают «заместителем», которому доверяет Google Cloud, а разграничение прав между слоями Kubernetes и GCP оказывается недостаточно строгим. Публичный идентификатор CVE в исходном материале не приводится.

Что делать

Специалисты рекомендуют организациям, использующим Config Connector, пересмотреть модель доступа: — ограничить круг пользователей, имеющих право создавать и изменять объекты Config Connector в кластерах; — применять принцип наименьших привилегий к сервисному аккаунту Google Cloud, под которым работает Config Connector, не наделяя его правами уровня всей организации без крайней необходимости; — использовать отдельные кластеры и сервисные аккаунты для разных команд и сред, чтобы компрометация одного кластера не открывала доступ ко всей организации; — включить аудит и мониторинг действий Config Connector, чтобы своевременно замечать подозрительные изменения IAM-политик и создание новых ресурсов; — проверить, есть ли у рядовых разработчиков права на запись объектов Config Connector, и при наличии — сузить их. Итог: атака наглядно демонстрирует, что доверие между Kubernetes и облачными сервисами должно быть явно ограничено — иначе один YAML-файл становится ключом ко всей организации GCP.

Источник: BleepingComputer