Kubernetes v1.35: CSI-драйверы получают токены сервисных аккаунтов через secrets

В Kubernetes v1.35, выпущенном в январе 2026 года, появилось долгожданное улучшение для разработчиков CSI-драйверов: новый механизм передачи токенов сервисных аккаунтов через поле secrets. Ранее токены передавались через volumecontext, что создавало риски безопасности из-за случайного логирования чувствительных данных. Теперь разработчики могут явно указать поддержку нового механизма, что повышает безопасность и устраняет уязвимости.

Новая опция: CSI Driver Opt-in for Service Account Tokens via Secrets Field

В Kubernetes v1.35 введена бета-функция, которая позволяет CSI-драйверам получать токены сервисных аккаунтов через поле secrets в NodePublishVolumeRequest. Это поле в спецификации CSI изначально предназначено для передачи чувствительных данных, в отличие от volumecontext, который не считается безопасным. Разработчикам драйверов нужно явно указать поддержку этой возможности в манифесте CSIDriver, установив поле secretsRequireServerAccountToken: true. Такой подход гарантирует, что токены не попадут в логи и не будут случайно раскрыты.

Почему это важно для безопасности?

Проблема передачи токенов через volumecontext была известна давно. Механизм TokenRequests, появившийся в более ранних версиях Kubernetes, позволял CSI-драйверам запрашивать токены для identity рабочих нагрузок, но передавал их в volumecontext. Это приводило к тому, что инструмент protosanitizer, используемый для очистки gRPC-запросов, не обрабатывал volumecontext как чувствительные данные, и токены попадали в логи. В результате были зафиксированы CVE-2023-2878 в Secrets Store CSI Driver и CVE-2024-3744 в Azure File CSI Driver. Каждый драйвер был вынужден реализовывать собственную логику санитизации, что приводило к неконсистентности и дополнительным рискам. Новый механизм решает эту проблему на уровне платформы, делая передачу токенов безопасной по умолчанию.

Как работает opt-in механизм?

Чтобы воспользоваться новым механизмом, разработчик CSI-драйвера должен добавить в манифест CSIDriver поле secretsRequireServerAccountToken: true. После этого kubelet начнёт передавать токены не в volumecontext, а в поле secrets NodePublishVolumeRequest. Важно, что это opt-in: старые драйверы продолжат получать токены через volumecontext без изменений, что обеспечивает обратную совместимость. Если драйвер заявил поддержку нового поля, kubelet не будет передавать токены через volumecontext, чтобы избежать дублирования. Таким образом, разработчики могут постепенно мигрировать, не нарушая работу существующих систем.

Какие шаги нужно предпринять для миграции?

Для разработчиков драйверов миграция включает несколько шагов. Во-первых, нужно обновить код драйвера для чтения токенов из поля secrets, а не из volumecontext. Во-вторых, необходимо установить secretsRequireServerAccountToken: true в манифесте CSIDriver. В-третьих, следует протестировать драйвер на Kubernetes v1.35 (или новее) с включённой функцией. Функция доступна по умолчанию, так как находится в бета-статусе. Важно отметить, что если драйвер не обновит код, но установит флаг, он перестанет получать токены — поэтому порядок действий критичен. Рекомендуется сначала обновить код, затем включить флаг.

Кого затронет и как

Нововведение в первую очередь касается разработчиков и мейнтейнеров CSI-драйверов, которые используют TokenRequests. Для них это шанс устранить уязвимости, связанные с утечкой токенов. Администраторы Kubernetes-кластеров также выиграют: обновлённые драйверы повысят общую безопасность кластера. Пользователи (разработчики приложений) не заметят изменений, но их рабочие нагрузки станут защищённее. В российском контексте это особенно актуально для компаний, использующих самописные или форкнутые CSI-драйверы — им стоит обратить внимание на обновление. Например, если ваша компания использует собственный драйвер для работы с облачными хранилищами, миграция на новый механизм снизит риск утечки токенов.

Как это повлияет на существующие драйверы?

Существующие драйверы, которые не обновятся, продолжат работать как раньше. Однако со временем, когда функция перейдёт в стабильный статус, старый способ может быть объявлен устаревшим и удалён. Поэтому рекомендуется начинать миграцию уже сейчас. Популярные драйверы, такие как Secrets Store CSI Driver и Azure File CSI Driver, уже работают над поддержкой нового механизма. Следите за их релизами.

Что будет дальше

Ожидается, что популярные CSI-драйверы, такие как Secrets Store CSI Driver и Azure File CSI Driver, вскоре выпустят версии с поддержкой нового механизма. В следующих выпусках Kubernetes возможен переход функции в стабильный статус и, вероятно, удаление старого способа передачи токенов через volumecontext. Разработчикам рекомендуется начинать миграцию уже сейчас, чтобы избежать проблем с совместимостью в будущем. Кроме того, это улучшение может стать основой для дальнейших изменений в безопасности Kubernetes, таких как более строгий контроль доступа к токенам.

Итог

Kubernetes v1.35 решает давнюю проблему безопасности CSI-драйверов, предоставляя правильный механизм передачи токенов сервисных аккаунтов. Это важный шаг к улучшению безопасности кластеров и снижению риска утечек чувствительных данных. Разработчикам стоит как можно скорее адаптировать свои драйверы, а администраторам — следить за обновлениями используемых драйверов. Новый механизм не только устраняет уязвимости, но и упрощает разработку, так как теперь не нужно реализовывать собственную санитизацию. Внедрение этой функции — пример того, как платформа может взять на себя ответственность за безопасность, освобождая разработчиков от рутинных задач.