# Secret обновился, доступ всё ещё старый: ротация файла и перечитывание

Диагностика: Secret обновился, доступ всё ещё старый: ротация файла и перечитывание. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-secret-volume-rotation/
Language: ru

Ротация Secret и применение credentials приложением — разные события. Kubernetes обновляет projected Secret files с eventual consistency, но subPath исключает обычные обновления. Программа, читающая файл один раз, может продолжать использовать старое значение даже после успешной projection.

## Найдите реальный источник credentials

Сохраните Secret reference, namespace, volumeMount и способ чтения приложения. Отдельно проверьте env injection: изменение объекта не заменяет значение окружения уже запущенного процесса. Для расследования нужны версии, имена и безопасные маркеры, а не полные секреты. Не выводите содержимое Secret, env dump или authorization header в журнал. Также определите upstream service, который принимает credentials, и его правила overlap: прекращение старого доступа может происходить независимо от обновления Kubernetes объекта.


[Официальный источник 1](https://kubernetes.io/docs/concepts/configuration/secret/).

## Проверьте projection boundary

Secret volume обновляется по механизму kubelet watch/cache/sync, поэтому API update и появление файла не обязаны совпасть по времени. Для subPath mount автоматическая projection не обновляется. Сравнивайте наличие новой версии без публикации значения, используя предусмотренный безопасный признак. Затем определите, следит ли приложение за изменением файла или сохраняет прочитанный credential в памяти. Наблюдатель одного inode может отличаться от повторного открытия пути при обновлении projection; используйте documented reload pattern клиента.


[Официальный источник 2](https://kubernetes.io/docs/concepts/storage/projected-volumes/).

## Разберите двухэтапную ротацию

В учебном сценарии принимающий сервис временно поддерживает старый и новый credential. Secret обновляется, приложение перечитывает файл, тест подтверждает новый доступ, после чего старый credential отзывается согласно правилам системы. Такая последовательность возможна только при реальной поддержке overlap у получателя. Статья не приписывает её каждому сервису. Если overlap отсутствует, нужен иной согласованный переход с известным перерывом, а не обещание бесшовной ротации только средствами Kubernetes.

| Событие | Безопасное подтверждение |
| --- | --- |
| Secret изменён | Версия объекта и время |
| Projection обновлена | Проверенный несекретный marker |
| Клиент перечитал | Событие reload или новый процесс |
| Новый доступ принят | Результат контрольной операции |

## Выберите поддерживаемое применение

Если клиент умеет reload credentials, проверьте его поведение и ошибки. Если читает только при старте, используйте управляемую замену Pod. Убедитесь, что rollout не требует отсутствующей запасной GPU-ёмкости. Перед отзывом старого credential проверьте все нужные реплики, а не единственный успешный запрос. Не копируйте новый Secret в image для удобства: это расширяет область хранения и связывает sensitive data с lifecycle артефакта, который может распространяться независимо.

## Проверьте отзыв и остатки

После перехода подтвердите ожидаемый отказ старого доступа на тестовом пути и работу нового. Проверьте, что логи не содержат values и что прежние временные файлы удаляются по предусмотренной процедуре. Артефакт связывает object version, projection, application reload и upstream acceptance. Это точнее, чем одна отметка «Secret обновлён». Повторяйте проверку после изменения mount или клиентской библиотеки: механизм чтения может измениться без изменения имени Kubernetes Secret.

Связанные разборы: [cloud gpu account team key rotation](/ru/journal/cloud-gpu-account-team-key-rotation/); [hardware security](/ru/journal/hardware-security/).