Коллеги, есть следующая архитектура: - "центральный" кластер волт, крутится в ЕС2

инстансах, авто-ансил ключом из AWS KMS
- 3 кластера волт крутятся в кубах, авто-ансил транзит ключами из центрального кластера (авторизация кубернетис)

есть дженкинс, который крутится в ЕС2 и аплаит терраформ конфиг волтов. С "центральным" кластером проблем нет: дженкинс авторизуется через AWS и применяет конфиг

затык - как дженкинсу авторизоваться в кубовых кластерах.
Пока додумался до следующего:
- в джобе, которая деплоит волт в куб, создавать аппроль и секрет и записывать их id в центральный кластер в секреты
- в джобе, которая применяет конфиг, дергать центральный кластер, получать аппроль и секрет-айди и уже с ними авторизовываться в нужном кубовом кластере.

Но вот чот не нравится мне, что секрет без ттл и ограничений на число использований.
Мож кто подскажет, как кошерно сделать?

P.S. "центральный" кластер для транзит ключей сделал, чтобы не экспозить, даже частично, креды AWS в кубе. При описанном сетапе никакие креды вообще не передаются никуда. По этой же причине не хочу давать дженкинсу кубовую авторизацию в волтах - придется токен SA где-то хранить в конфигах. Думал сделать авторизацию TLS и поднять PKI в центральном кластере, но, кажется, есть ряд ограничений со стороны кастомера и доступов к ключу СА

Не призыв к действию, но я просто сделал джобу в кубере, которая генерит токен с TTL раз в 30 минут и загружает в Vault, jenkins в свою очередь просто берет этот токен во время запуска пайплайна (авторизуясь по аппРоли) и использует его для авторизации в кубе. Не уверен, что лучшее решение, точно есть что-то адекватнее, но в моем случае работает хорошо.

так а как дженкинс авторизуется по аппроли? окей, дать ему в конфиг role_id можно, но давать и role_id, и secret_id это как раз то, чего хочется избежать, то есть дженкинсу надо как-то авторизоваться в волте, чтобы получить эти айдишки. И вот как раз на этом у меня затык

Для аппРоли, вроде как и role_id и secret_id нужны одновременно. Ему же нужно как-то токен получить. Хотя я могу ошибаться

не ошибаетесь, так и есть. Походу, надо писать фича-реквест, чтобы один кластер волт мог валидировать токены другого кластера

For advanced usage, requiring a SecretID can be disabled via an AppRole's bind_secret_id parameter, allowing machines with only knowledge of the RoleID, or matching other set constraints, to fetch a token