ТЕХНОЛОГИИ

Токен ServiceAccount истёк: audience и обновление projected volume

В этом материале
ГЛАВНОЕ ЗА МИНУТУ

Projected ServiceAccount token имеет срок действия и audience. Kubelet обновляет файл, но клиент обязан использовать ротируемое значение, а не навсегда кешировать первую строку. Ошибка expired или invalid audience требует проверки identity token отдельно от обычных LLM API keys.

Projected ServiceAccount token имеет срок действия и audience. Kubelet обновляет файл, но клиент обязан использовать ротируемое значение, а не навсегда кешировать первую строку. Ошибка expired или invalid audience требует проверки identity token отдельно от обычных LLM API keys.

Найдите workload identity

Сохраните serviceAccountName, projected volume, token path и назначение получателя. Не выводите сам bearer token в отчёт. Проверьте, нужен ли приложению доступ к Kubernetes API вообще: автоматическое предоставление credentials не должно становиться неопределённым дополнительным доступом. Для внешнего получателя нужны его реальные правила trust и token validation. Наличие ServiceAccount в namespace само по себе не означает, что любой внешний сервис обязан принимать выданный ему токен.

Официальный источник 1.

Проверьте audience и срок

Audience определяет предназначенного получателя. Recipient должен проверять соответствие своей identity заявленному audience, а не принимать любой корректно подписанный token. ExpirationSeconds задаёт ожидаемый срок при ограничениях API server. Kubelet обновляет projected token по документированной политике, но приложение может продолжать использовать старую копию. Сохраните настройки и безопасные временные признаки без полного payload. В разных версиях и административных настройках фактическое поведение срока следует подтверждать, а не выводить из единственного примера YAML.

Официальный источник 2.

Разберите истёкший кеш

В учебном приложении token file читается один раз при запуске. Через некоторое время kubelet уже записал новое значение, но клиент отправляет прежний cached bearer. Перезапуск временно восстанавливает доступ, после чего проблема повторяется. Это признак для проверки reload logic, а не повод создать бессрочный legacy Secret. Отдельно исследуйте subPath: projected volume, смонтированный таким способом, не получает обычных обновлений, поэтому источник старого значения может быть ещё до клиента.

ГраницаЧто подтвердить
ВыдачаНужный ServiceAccount и audience
ProjectionОбновление доступного файла
КлиентПовторное чтение вместо вечного кеша
ПолучательПроверка audience и времени

Исправьте потребление токена

Используйте поддерживаемый клиентом способ чтения ротируемого файла и обновления соединений или auth state. Проверьте mounts и исключите непреднамеренный subPath. Для клиента без reload спланируйте подходящий lifecycle, понимая ограничения такого подхода. Не расширяйте RBAC и не снимайте expiration только ради исчезновения сообщения 401: это меняет другую границу доступа. Если причина в audience, исправьте согласование с получателем вместо использования токена для чужого назначения.

Проверьте переход через ротацию

На стенде наблюдайте как минимум один реальный цикл обновления и контрольный доступ до/после. Сохраните времена, настройки projection и результат без token values. Успех включает продолжение работы клиента после смены файла и ожидаемый отказ неподходящего audience. Артефакт помогает отличить expired cache от неправильной trust configuration. После обновления библиотеки повторите опыт: новый auth implementation может иначе кешировать credentials, хотя Kubernetes manifest и имя файла остались прежними.

Связанные разборы: hardware security; kubernetes gpu scheduling.

← Все материалы