Сервис доказывает идентичность через настроенный auth method. Vault проверяет её, выдаёт токен с политиками и проверяет право запросить конкретный путь, например database/creds/orders-readonly. Роль database secrets engine определяет создание учётной записи, её права и сроки. Название сервиса или знание имени роли сами по себе доступа не дают.
Как Vault понимает, что конкретному сервису можно выдать временный пароль?
Цепочка выдачи временного пароля: проверка идентичности сервиса, политики Vault, роль database secrets engine и отдельные права в БД.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Vault не доверяет произвольной строке «я сервис orders». Администраторы заранее настраивают способ проверки идентичности и соответствие между подтверждёнными признаками клиента и разрешёнными действиями.
Сначала — аутентификация. Например, задание GitLab предъявляет подписанный ID token. JWT auth method проверяет подпись, срок действия и настроенные ограничения, включая издателя, audience и связанные claims. Для такой интеграции важно ограничить доступ нужным проектом и, где требуется, защищённой веткой или тегом, а не принимать любой токен данного GitLab. JWT auth, интеграция GitLab.
Затем — авторизация. После успешного входа клиент получает Vault token с назначенными политиками. При запросе учётных данных проверяются путь и операция. Например, политика может разрешать только read для database/creds/orders-readonly. Успешная аутентификация не означает доступ ко всем секретам; разрешения задаются явно. Политики Vault.
Далее — выдача секрета. Роль orders-readonly в database secrets engine определяет подключение к нужной БД, инструкции создания пользователя и настройки срока действия. Vault использует настроенную служебную учётную запись БД и возвращает клиенту отдельные данные с lease. Фактические SQL-права задаются конфигурацией выдачи, а не красивым именем readonly. Database secrets engine.
Не смешивайте auth role, политику Vault, роль secrets engine и роль/пользователя внутри БД: они решают разные задачи и не обязаны одинаково называться. Это не «роль пользователя интерфейса».
Полученными данными приложение подключается к БД, которая проверяет их своими механизмами. При диагностике последовательно проверяют вход в Vault, разрешение на путь и создание пользователя в БД, не выводя токены и пароли в журнал. TTL токена Vault, lease секрета и срок жизни соединения приложения — также разные величины.