Разделите динамические учётные данные с lease и ротацию пароля постоянного пользователя. Продление lease не обязательно меняет пароль. Расскажите, что настраивали лично, как приложение получало обновление и что происходило при истечении срока или ошибке отзыва. TTL секрета не равен времени жизни соединения приложения с БД.
Как работал механизм ротации паролей и временных учётных данных: вы его настраивали сами или только использовали?
Как описать реальную схему обновления секретов: динамические учётные данные, lease, ротацию статического пароля и изменения на стороне приложения.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала уточните, какой механизм действительно применялся. «Пароль менялся раз в час» недостаточно: это могла быть ротация постоянной учётной записи, выдача новой временной или только повторное чтение неизменного секрета.
У Vault есть разные сценарии. При динамической выдаче database secrets engine создаёт учётные данные по настроенной роли. При static role сохраняется привязка к определённому пользователю БД, пароль которого Vault ротирует. Само хранение пароля в KV не превращает его в автоматически ротируемый пароль БД. Database secrets engine.
Динамический секрет сопровождается lease: важны фактически выданные TTL, возможность продления и предельный срок. Продление lease не следует описывать как обязательную генерацию нового пароля. Клиент проверяет результат продления и при необходимости получает замену; истечение или отзыв запускают механизм отзыва секрета. Lease, renew and revoke.
Расскажите свою часть процесса:
- Кто настраивал подключение к БД, роли, сроки и операции создания/отзыва.
- Кто реализовывал получение секретов, продление и доставку обновлений приложению.
- Как приложение переводило новые подключения на актуальные данные и освобождало старые.
- Кто проверял сбои ротации, недоступность Vault или БД и ошибки повторного подключения.
Не обещайте, что в момент окончания TTL все открытые соединения автоматически закроются. Это зависит от БД, плагина и операций отзыва; управление пулом соединений нужно проверять отдельно. Успешная запись нового пароля в файл также не доказывает, что приложение его перечитало.
Если вы только использовали готовую интеграцию, так и скажите, затем объясните наблюдаемый жизненный цикл. Если настраивали её сами, приведите реальный способ проверки выдачи, обновления и отказа со старыми данными. Числа, инциденты и результаты добавляйте только из собственного опыта.