Уточните, что подразумевается под «авторизацией». Вход в Vault, право получить секрет и вход в БД — разные этапы. Расскажите, выдавали ли через Vault реквизиты приложениям, сотрудникам или обоим, какие политики использовали и что делали лично. Само внедрение Vault не доказывает, что все пользователи БД были переведены на него.
Вы использовали Vault только для входа или также для выдачи учётных данных пользователям БД?
Как разделить вход в Vault, разрешение на секрет и последующее подключение человека или приложения к базе данных.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Не отвечайте «да» на неоднозначную формулировку. Сначала разделите аутентификацию клиента в Vault и получение секрета для другого сервиса.
Для реального проекта опишите, кто пользовался системой: CI-задания, работающие приложения, разработчики, DBA или несколько групп. У человека и сервиса могут быть разные способы подтверждения личности, политики и сроки доступа. Auth methods Vault решают именно задачу входа, а не автоматически предоставляют доступ ко всем базам.
Затем поясните, что выдавалось:
- сохранённый статический пароль из KV;
- пароль постоянной учётной записи с настроенной ротацией;
- динамическая учётная запись с ограниченным сроком;
- иной тип секрета.
Не смешивайте эти механизмы. После получения реквизитов клиент обычно подключается к самой БД; наличие токена Vault не означает, что БД умеет принять его вместо своего пароля.
Покажите границы прав: например, доступ сотрудника к диагностике и доступ приложения к рабочей схеме могут различаться. Не используйте общий административный пароль как универсальную иллюстрацию безопасного решения.
Закончите своей ролью: настраивали интеграцию, выдавали доступ по утверждённому процессу или только получали готовые реквизиты. Если какая-то группа пользователей продолжала работать по старой схеме, скажите это прямо. Ответ должен описывать фактический охват внедрения, а не возможности продукта вообще.