В типичной схеме database secrets engine клиент аутентифицируется в Vault и получает временные учётные данные БД. Затем он подключается к самой БД обычным способом. На стороне БД нужны выделенная учётная запись для управления пользователями, необходимые права, сетевой доступ и корректная аутентификация. Это не универсальная федерация, при которой БД начинает доверять любому токену Vault.
Как подключаться к БД после внедрения Vault и что настроить на стороне БД?
Схема динамических учётных данных: пользователь входит в Vault, получает отдельные реквизиты БД и подключается напрямую. Почему БД не обязана проверять токен Vault.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала уточните выбранную интеграцию. Vault не превращает любую БД в сервис, который автоматически принимает его токены. Рассмотрим распространённую схему динамических учётных данных через database secrets engine.
Путь пользователя или приложения:
- Аутентифицироваться в Vault настроенным для своей роли способом.
- Получить разрешение политикой Vault на выдачу учётных данных нужной database-role.
- Запросить реквизиты: Vault через плагин создаёт пользователя в БД с заданными правами и возвращает данные подключения вместе с информацией об аренде — lease.
- Подключиться к адресу самой БД этими реквизитами. Vault в этой схеме не проксирует SQL-трафик.
На стороне БД создают отдельную служебную учётную запись для Vault. Ей нужны права на предусмотренное управление ролями и выдачу доступа, но не следует без проверки назначать максимально возможные привилегии. Также обеспечивают сетевую доступность, защищённое соединение и штатные правила аутентификации. Для PostgreSQL это, в частности, согласованные правила pg_hba.conf; включать метод trust ради интеграции не требуется. Есть отдельная документация плагина PostgreSQL.
В Vault настраивают плагин и соединение, допустимые роли, правила создания и отзыва пользователей, сроки действия и политики доступа клиентов. Роль Vault и роль БД — связанные настройкой, но разные сущности. Доверие сертификату сервера при TLS тоже не заменяет права учётной записи.
Клиент должен учитывать срок действия реквизитов, обновление или повторную выдачу и переподключение. Ошибки отзыва и поведение уже открытых сеансов проверяют отдельно, не обещая мгновенного закрытия всех соединений одним TTL.
Если используется хранение статического пароля либо ротация существующей учётной записи, сценарий другой: это не динамическое создание пользователя по запросу новых реквизитов.