KV secrets engine хранит произвольные секреты, например токены внешних интеграций. Он не меняет пароль во внешней системе автоматически только потому, что значение записали в Vault. Расскажите, кто обновлял секрет, как ограничивали доступ и как приложение получало новую версию. KV v2 поддерживает версии, KV v1 хранит текущее значение.
Использовали ли вы KV-хранилище Vault для секретов без автоматической ротации?
Чем хранение статического секрета отличается от динамической выдачи, что дают версии KV и кто отвечает за обновление значения.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Начните с реального типа секрета и своей роли, не раскрывая само значение. В KV могут храниться токен внешнего API, пароль системы без динамической интеграции или другой конфиденциальный параметр.
KV secrets engine — хранилище ключей и значений. Это не database secrets engine: запись нового значения в KV не заставляет внешнюю БД или API сменить пароль. Такую смену должен выполнять отдельный согласованный процесс.
В ответе раскройте:
- кто создавал и обновлял секрет;
- как разграничивали пути по приложениям и окружениям;
- кто имел право читать, менять и удалять значения;
- как приложение получало обновление;
- что делали при компрометации или ошибочной записи.
KV v1 хранит последнее значение, KV v2 позволяет работать с версиями и поддерживает check-and-set. Версионирование помогает восстановить ошибочно изменённую запись, но возврат старого значения не восстановит доступ, если старый пароль уже отозван во внешней системе. Также не стоит считать soft delete гарантированным физическим уничтожением истории.
Различайте удаление доступа к Vault и отзыв уже выданного статического секрета: клиент мог сохранить копию. Для реального отзыва обычно нужно изменить или аннулировать секрет там, где он действует.
Если пользовались только чтением готовых значений, прямо обозначьте это. Не называйте себя автором механизма ротации, если отдельной ротации не было.