OpenBAO: Manage, store, and distribute sensitive data
1–7 of 7 posts
Re: OpenBAO: Manage, store, and distribute sensitive data
#2Ever since the IBM acquisition of Hashi I've been using this a lot more with my clients to save cost
Re: OpenBAO: Manage, store, and distribute sensitive data
#3Not directly related to openbao, but I've thought about this for awhile that I'd like to use ssh certificates instead of ssh keys to allow an agent a time limited SSH access to a server, and that seems to work for gating the initial connection, but I haven't yet figured out how to enforce the established connection dies after a certain time. I could maybe hand roll a solution with ExposeAuthInfo and ForceCommand wrapper, but it feels like this sort of thing should be handled delicately..
Re: OpenBAO: Manage, store, and distribute sensitive data
#4My dream configuration in the past was Vault, protected by step-ca's ACME implementation, with an IdP like KanIDM for SSO.
But it seems like there is so much feature creep: OpenBao now has its own ACME server. And KanIDM is considering it... Why is every app vying to be my root of trust?
Re: OpenBAO: Manage, store, and distribute sensitive data
#5Ever since the IBM acquisition of Hashi I've been using this a lot more with my clients to save cost
Have you noticed any issues/differences compared to Vault? We ended up moving completely away from Vault because we didn't use most of its features and it wasn't worth the cost.
I was going to migrate my homelab from vault oss -> openbao, but I'm debating on whether that's even worth it or just going back to gpg encrypted files or something.
Re: OpenBAO: Manage, store, and distribute sensitive data
#6Ever since the IBM acquisition of Hashi I've been using this a lot more with my clients to save cost
Have you noticed any issues/differences compared to Vault? We ended up moving completely away from Vault because we didn't use most of its features and it wasn't worth the cost. I was going to migrate my homelab from vault oss -> openbao, but I'm debating on whether that's even worth it or just going back to gpg encrypted files or something.
If you're going to expose static secrets to your app, it kind of doesn't matter whether they are in a single vault or in a gpg encrypted file or something. The real benefit of a vault IMHO is to distribute dynamic certificates instead of a static secret, so that way it's time-boxed, and the static secret (private key) never actually leaves the vault.
Re: OpenBAO: Manage, store, and distribute sensitive data
#7My dream configuration in the past was Vault, protected by step-ca's ACME implementation, with an IdP like KanIDM for SSO. But it seems like there is so much feature creep: OpenBao now has its own ACME server. And KanIDM is considering it... Why is every app vying to be my root of trust?
Vault has had PKI since pre-v1; ACME was introduced in 2022 to modernize its APIs.