By restructuring storage--which, may, yes, lead to some operational differences--we can add per-namespace seal mechanisms in our next release (v2.4.0 -- design doc https://github.com/openbao/openbao/issues/1170), giving encryption key separation. Layer that with per-namespace storage engines (or light partitions -- separate tables) and true horizontal _write_ scalability becomes a possibility.
Yep, I have been just reading that for unrelated reasons before happening on the HN post :)
At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.
Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there
Nice! The biggest gap with Vault Enterprise that I'm hoping we'll get to next release will be horizontal scalability of read requests.
We should be fairly compatible otherwise! Our helm chart just got a few more maintainers (I confess I lack the skills to maintain it, JanMa has been doing a great job there) though we've been relying on the pre-BUSL operator and CSI from upstream due to lack of resources.
Things like ESO and Cert-Manager should just continue to work :-)
If I wasn't virulently anti-helm I'd probably help maintain it, as it is I treat Helm as necessary evil but never write any charts ^^;
Another idea I just had yesterday, and which I've seen partially executed by others, was serverless Vault/OpenBao - the tricks I've seen used various FUSE filesystems, but I wonder if an S3-compatible backend couldn't be added one day :)
We've made an effort to keep API compatibility with Vault wherever possible, also with the new namespaces implementation. Most of the tooling which works with Vault today will also work with OpenBao
If you have reproducers for behavioral differences, happy to take issues and PRs!
(Entities was discussed here: https://github.com/openbao/openbao/issues/1110#issuecomment-...)
Right, check out our vision post as well: https://openbao.org/blog/vision-for-namespaces/
By restructuring storage--which, may, yes, lead to some operational differences--we can add per-namespace seal mechanisms in our next release (v2.4.0 -- design doc https://github.com/openbao/openbao/issues/1170), giving encryption key separation. Layer that with per-namespace storage engines (or light partitions -- separate tables) and true horizontal _write_ scalability becomes a possibility.
Yep, I have been just reading that for unrelated reasons before happening on the HN post :)
At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.
Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there
Nice! The biggest gap with Vault Enterprise that I'm hoping we'll get to next release will be horizontal scalability of read requests.
We should be fairly compatible otherwise! Our helm chart just got a few more maintainers (I confess I lack the skills to maintain it, JanMa has been doing a great job there) though we've been relying on the pre-BUSL operator and CSI from upstream due to lack of resources.
Things like ESO and Cert-Manager should just continue to work :-)
If I wasn't virulently anti-helm I'd probably help maintain it, as it is I treat Helm as necessary evil but never write any charts ^^;
Another idea I just had yesterday, and which I've seen partially executed by others, was serverless Vault/OpenBao - the tricks I've seen used various FUSE filesystems, but I wonder if an S3-compatible backend couldn't be added one day :)
You should read this RFC: https://github.com/openbao/openbao/issues/1340
If you use that with a PostgreSQL backend (which doesn't require raft and has faster leader changes), it might be possible.
Feel free to drop me a mail as well, email is in my profile.
We've made an effort to keep API compatibility with Vault wherever possible, also with the new namespaces implementation. Most of the tooling which works with Vault today will also work with OpenBao