Всем привет!

У нас была отдельная роль для Jenkins, обладающая доступом к SecretID, несколько приложений, которые использовали AppRole (RoleID и SecretID) и обладали своими собственными ролями на чтение секретов…

В статье представлен интересный подход использования AppRole в соответствии со следующей схемой:
🍭 Создаем Role [1] для приложения, используем AuthMethod: AppRole
🍭 Создаем политику [‘read’, ‘list’], применяем к Role приложения [1]
🍭 Получаем RoleID [RiD] приложения
🍭 Создаем Role [2] для Jenkins, используем AuthMethod: Token, генерируем Token [T]
🍭 Создаем политику [‘read’, ‘list’, ‘update’] для SecretID, которую применяем к Role Jenkins [2]
🍭 Настраиваем VAULT_TOKEN [T] и RoleID [RiD] как переменные окружения в Jenkins
🍭 Внутри отдельного build извлекаем SecretID: при помощи VAULT_TOKEN [T] Jenkins аутентифицируется в Vault и «изменяет» SecretID (права у него есть, [2]), записывает его в переменную [SiD]
🍭 Далее – используя RoleID [RiD] и SecretID [SiD] получаем доступ к секретам. Готово!

В рассматриваемом сценарии используется только одна относительно long-lived сущность, а именно – token, который используется Jenkins для аутентификации в Vault. Все остальные сущности – «одноразовые» или могу обладать небольшим сроком жизни (в зависимости от реализованных настроек).