16 мая 2026 года BleepingComputer сообщил о конфликте между Microsoft и исследователем безопасности Justin O’Leary вокруг Azure Backup for AKS. Исследователь утверждает, что уязвимость позволяла пользователю с ролью Backup Contributor получить cluster-admin в Kubernetes-кластере, а Microsoft настаивает, что это не была уязвимость и CVE не нужен. Для владельцев AKS-кластеров главная практическая задача сейчас — проверить, кому выданы backup-роли, как настроен Trusted Access и нет ли слишком широких прав у сервисных идентичностей.
Спор начался с отчёта о повышении привилегий в Azure Backup for AKS
Публичная новость появилась после материала BleepingComputer от 16 мая 2026 года. Издание пишет, что Microsoft отклонила отчёт о критической проблеме в Azure Backup for AKS и не стала выпускать CVE, хотя исследователь утверждает, что поведение сервиса затем изменилось.
Речь идёт об Azure Backup for AKS — сервисе резервного копирования для Azure Kubernetes Service. AKS — это управляемый Kubernetes в облаке Microsoft, а Kubernetes часто используется для запуска контейнерных приложений: API, backend-сервисов, микросервисов, очередей, воркеров и внутренних платформ.
По словам исследователя Justin O’Leary, проблема позволяла пользователю с ролью Backup Contributor в Azure получить права cluster-admin внутри Kubernetes-кластера. Это очень высокий уровень доступа: cluster-admin фактически означает полный контроль над кластером, включая возможность читать секреты, изменять ресурсы, запускать workloads и вмешиваться в работу приложений.
Важно: Microsoft не согласилась с такой оценкой. Компания заявила BleepingComputer, что описанное поведение было ожидаемым, требовало уже существующих административных привилегий в окружении клиента и не являлось уязвимостью. Поэтому CVE и CVSS-оценка не выпускались.
Проблема упиралась в границу между Azure RBAC и Kubernetes RBAC
Ключевая часть истории — пересечение двух разных моделей прав.
В Azure есть Azure RBAC — система ролей на уровне облачных ресурсов. В Kubernetes есть своя модель доступа — Kubernetes RBAC, которая управляет правами внутри кластера. В идеальной схеме роль в Azure не должна автоматически превращаться в полный административный доступ внутри Kubernetes, если такой доступ явно не выдан.
Исследователь описывает сценарий как ошибку типа Confused Deputy. Простыми словами, это ситуация, когда один доверенный компонент системы выполняет действие от имени пользователя шире, чем должен. Пользователь напрямую не имеет нужных прав, но заставляет более привилегированный сервис выполнить операцию за него.
В этом случае, по версии исследователя, пользователь с ролью Backup Contributor мог запустить процесс настройки бэкапа для AKS-кластера. Azure Backup использовал механизм Trusted Access, который даёт Azure-сервисам доступ к Kubernetes API. В результате сервис якобы автоматически создавал доступ, достаточный для получения cluster-admin.
Microsoft в своей позиции утверждает обратное: по оценке компании, сценарий требовал уже существующих административных прав в клиентском окружении, а значит не соответствовал критериям отдельной уязвимости.
Trusted Access стал центральным элементом всей истории
Официальная документация Microsoft объясняет, что Azure Backup for AKS требует установки Backup extension внутри AKS-кластера, а Backup vault взаимодействует с этой extension для операций резервного копирования и восстановления. Там же указано, что для поддержки разных типов кластеров необходимо включить Trusted Access между AKS-кластером и Backup vault, чтобы vault получил специальные разрешения для backup-операций.
Отдельная документация по Trusted Access описывает этот механизм как способ дать Azure-сервисам безопасный доступ к Kubernetes API server без отдельной private endpoint-модели. Microsoft подчёркивает, что Trusted Access должен использовать явное согласие через role binding, а не просто широкие административные права.
Именно поэтому спор важен не только как «ещё одна облачная уязвимость». Он касается базового вопроса доверия к границам доступа: где заканчиваются права Azure-роли и где начинаются права внутри Kubernetes.
Исследователь утверждает, что атака была закрыта без публичного advisory
В своём техническом разборе Justin O’Leary пишет, что обнаружил проблему в марте 2026 года, сообщил в Microsoft Security Response Center 17 марта, а затем передал кейс в CERT/CC. По его словам, CERT/CC подтвердил проблему как VU#284781, но позже кейс был закрыт, а CVE так и не появился: O’LearySec — Azure Backup AKS silent patch.
Главное утверждение исследователя — Microsoft якобы изменила поведение сервиса без публичного security advisory. Он указывает, что теперь прежний путь атаки возвращает ошибку:
UserErrorTrustedAccessGatewayReturnedForbidden
Также исследователь утверждает, что теперь Trusted Access должен быть настроен заранее вручную, а для некоторых операций появились дополнительные проверки прав у managed identity. По его версии, это показывает, что поведение действительно было изменено после отчёта.
Microsoft, согласно комментарию BleepingComputer, с этим не согласна и заявляет, что изменений продукта для исправления отчёта не было. Поэтому в статье корректнее говорить не «Microsoft скрыла уязвимость», а «исследователь утверждает, что уязвимость была тихо закрыта; Microsoft это оспаривает».
Отсутствие CVE осложняет работу защитников
CVE — это публичный идентификатор уязвимости. Он нужен не только для новостей и отчётов, но и для практической работы: инвентаризации, risk management, compliance, сканеров, SIEM, внутренних тикетов и отчётности перед безопасностью.
Когда CVE нет, организациям сложнее ответить на простые вопросы:
- затрагивала ли проблема их окружение;
- в какой период риск был актуален;
- какие роли и identities нужно проверить;
- нужно ли фиксировать инцидент как security exposure;
- какие команды должны получить задачу на аудит.
Для крупных компаний это особенно чувствительно. Kubernetes-кластеры часто содержат секреты, токены доступа, конфигурации приложений и сетевые настройки. Если гипотетический путь к cluster-admin действительно существовал, он мог бы стать не просто технической ошибкой, а способом расширить доступ внутри production-инфраструктуры.
Администраторам AKS стоит проверить backup-роли и Trusted Access
Даже если организация принимает позицию Microsoft и не считает ситуацию уязвимостью, повод для проверки всё равно есть. История показывает, насколько опасными могут быть вспомогательные роли вокруг backup-инфраструктуры.
Минимальный практический чек-лист для команд, которые используют Azure Backup for AKS:
| Зона проверки | Что проверить |
| Azure RBAC | Кому выдана роль Backup Contributor и на каком scope |
| Backup vault | Какие vault имеют доступ к AKS-кластерам |
| Trusted Access | Какие role binding созданы между Azure-сервисами и AKS |
| Managed identities | Какие права есть у vault MSI, cluster MSI и extension identity |
| Snapshot resource group | Не выданы ли лишние роли на resource group со снимками |
| Kubernetes RBAC | Нет ли неожиданных cluster-admin binding |
| Журналы | Были ли необычные операции включения backup, restore или изменения backup policy |
Отдельно стоит проверить, не выдавалась ли роль Backup Contributor по принципу «для удобства» широким группам пользователей или CI/CD-сервисам. Backup-инфраструктура часто воспринимается как вспомогательная, но на практике она может иметь доступ к данным, snapshot-ресурсам и операциям восстановления.
История подчёркивает слабое место облачной безопасности
Главный урок этой ситуации — облачные роли нельзя оценивать только по названию. Роль «Backup Contributor» звучит ограниченно, но backup-сервисы часто работают рядом с критически важными данными и высокими привилегиями.
В Kubernetes это особенно заметно. Резервное копирование и восстановление — не просто копирование файлов. Backup-система может читать манифесты, работать с persistent volumes, восстанавливать ресурсы, взаимодействовать с API server и создавать объекты в кластере. Если такая система получает слишком широкую доверенную связь с кластером, ошибка в логике разрешений может стать путём к серьёзной эскалации.
Для бизнеса это означает простую вещь: безопасность AKS зависит не только от настроек самого Kubernetes. Нужно регулярно проверять весь контур вокруг него — Azure RBAC, identities, backup vault, storage, snapshot groups, extensions и автоматические доверенные интеграции.
Публичного признания уязвимости пока нет, но аудит прав откладывать не стоит
На текущий момент ситуация остаётся спорной: исследователь говорит о критической privilege escalation и тихом исправлении, Microsoft отрицает наличие уязвимости и не выпускает CVE. Свежий публичный повод подтверждён материалом BleepingComputer от 16 мая 2026 года, но официального Microsoft advisory по этой конкретной проблеме нет.
Практический вывод для владельцев Azure Backup for AKS — не ждать формального CVE, а провести аудит прав. Проверьте роли Backup Contributor, Trusted Access role bindings, managed identities и журналы backup-операций. Даже если конкретный сценарий в вашей инфраструктуре невозможен, такая проверка снизит риск похожих ошибок на границе Azure RBAC и Kubernetes RBAC.
