В компоненте синхронизации секретов HashiCorp Vault и Kubernetes обнаружена уязвимость, которая дает пользователю с ограниченными правами возможность читать произвольные файлы из файловой системы пода оператора и передавать их содержимое на контролируемый адрес. В зависимости от содержимого прочитанных файлов атака может привести к повышению привилегий внутри кластера. Проблема затрагивает версии Vault Secrets Operator с 1.3.0 по 1.4.1 включительно, исправление вышло в версии 1.5.0.
Уязвимость CVE-2026-8715
Vault Secrets Operator - это инструмент для автоматической передачи секретов из HashiCorp Vault в Kubernetes Secrets. Оператор работает внутри кластера, отслеживает изменения в пользовательских ресурсах и создает или обновляет секреты Kubernetes. Для аутентификации в Vault он поддерживает несколько методов, включая AppRole. AppRole удобен для рабочих нагрузок, у которых нет привязанного к человеку аккаунта: роль определяет набор политик доступа к секретам, а секретный идентификатор выступает как одноразовый ключ. Оператор должен получить этот идентификатор перед тем, как запрашивать секреты из Vault.
В версии 1.3.0 в ресурсы VaultAuth и VaultAuthGlobal добавили поле secretIDPath, позволяющее администратору указать путь к файлу с Secret ID, смонтированному в под оператора. Это удобно для сценариев, когда идентификатор доставляется в под как часть файловой системы. VaultAuth и VaultConnection - это пользовательские ресурсы Kubernetes, которые пользователи создают в своих namespace для настройки подключения оператора к Vault. VaultAuth определяет метод аутентификации и параметры, VaultConnection - адрес Vault и параметры соединения, а VaultStaticSecret указывает, какие секреты нужно синхронизировать.
При проверке пути, переданного в secretIDPath, оператор ограничивался проверкой на обходные последовательности и подтверждением, что целевой файл является обычным файлом и не превышает лимит размера. При этом никак не ограничивалось, какие файлы на поде можно указывать. Одновременно адрес подключения к Vault задается через другой пользовательский ресурс - VaultConnection. Совокупность этих факторов открывает путь к атаке.
Пользователь, обладающий правами на создание и изменение VaultAuth, VaultConnection и VaultStaticSecret в пределах своего namespace, может настроить аутентификацию так, чтобы оператор считал содержимое произвольного файла с собственного пода. Например, это может быть файл с переменными окружения, конфигурацией или сертификатами. Затем пользователь задает в VaultConnection адрес контролируемого им сервера. При обработке запроса AppRole оператор считывает указанный файл и отправляет его содержимое в составе запроса на этот адрес. По сути, оператор превращается в канал для эксфильтрации данных.
Для эксплуатации уязвимости необходима аутентифицированная учетная запись Kubernetes с упомянутыми правами. Такие права соответствуют роли редактора, которая публикуется в Helm-чарте оператора для конечных пользователей. Поэтому уязвимость актуальна прежде всего для мультитенантных кластеров, где арендаторам предоставлена возможность работать с этими ресурсами. Если таких прав нет, то атака невозможна.
Последствия зависят от того, какие файлы доступны на поде оператора. В типичной установке там могут лежать токены доступа к Kubernetes API, учетные данные для подключения к Vault, закрытые ключи и другие чувствительные данные. Их получение может позволить злоумышленнику расширить свои полномочия за пределы собственного namespace, а в некоторых случаях и получить контроль над кластером. Однако точный перечень доступных файлов зависит от конкретной конфигурации.
Уязвимости присвоен идентификатор CVE-2026-8715. В бюллетене HashiCorp не указано об использовании проблемы в реальных атаках, поэтому речь идет о превентивном обновлении. Разработчики представили версию 1.5.0, в которой поле secretIDPath полностью удалено. Вместо него теперь применяется spec.appRole.secretRef, ссылающийся на Kubernetes Secret, содержащий AppRole Secret ID. Такой подход исключает возможность указать произвольный файл, поскольку оператор обращается только к объекту Secret, созданному явно через API Kubernetes.
Администраторам, использующим версии 1.3.0 и 1.4.1, рекомендуется спланировать обновление до 1.5.0. Тем, кто уже настроил secretIDPath, необходимо перенести Secret ID в отдельный Kubernetes Secret и заменить в VaultAuth ссылку на него. Без этой миграции конфигурация после обновления может перестать работать, так как поле исчезнет.
Эта ситуация напоминает о том, что права на создание ресурсов, влияющих на поведение операторов, следует считать привилегированными даже в пределах отдельного namespace. Пользователь, способный управлять подобными объектами, получает возможность влиять на работу доверенного компонента. В данном случае недостаточная проверка пути и использование пользовательского адреса Vault привели к серьезной утечке данных. Подобные ошибки встречаются, когда разработчики чрезмерно доверяют пользовательскому вводу в конфигурационных ресурсах.
После обновления стоит также пересмотреть выданные пользователям права на VaultAuth и VaultConnection. Чем меньше субъектов имеют возможность изменять эти ресурсы, тем ниже риск повторения похожих проблем. В более широком смысле, любые пользовательские ресурсы, управляющие поведением операторов в Kubernetes, должны рассматриваться как потенциально опасные, а доступ к ним должен предоставляться по принципу минимальной необходимости.
Ссылки
