openbao secrets engine for application-specific credential refresh #1217

New issue

Open

opened 2026-07-18 18:33:07 +02:00 by kiara · 0 comments

kiara commented

2026-07-18 18:33:07 +02:00

Owner

our current generateFiles approach to secrets was based on clan's vars, keeping the generation on the consuming application's side, then statically storing it in openbao.

while this allows reusing the application binaries from the consumer node (allowing the openbao instance to not have to worry about it), the drawback to this approach is that it is not native to openbao's concerns: openbao secret engines would allow putting credential generating logic on the openbao side, such that it would be empowered to refresh credentials as needed.

as such, we may well be better off reconciling these approaches, putting openbao in charge of potential credential refreshes for such credentials as well, for in as far as applicable - such refreshes would need to be confirmed with the applications as well, such that we wouldn't just throw away our sole working credential.

our current `generateFiles` approach to secrets was based on clan's vars, keeping the generation on the consuming application's side, then statically storing it in openbao. while this allows reusing the application binaries from the consumer node (allowing the openbao instance to not have to worry about it), the drawback to this approach is that it is not native to openbao's concerns: openbao [secret engines](https://openbao.org/docs/secrets/) would allow putting credential generating logic on the openbao side, such that it would be empowered to refresh credentials as needed. as such, we may well be better off reconciling these approaches, putting openbao in charge of potential credential refreshes for such credentials as well, for in as far as applicable - such refreshes would need to be confirmed with the applications as well, such that we wouldn't just throw away our sole working credential.

Rows
Columns