The current implementation, in the beta release, differs somewhat from upstream in how it handles entities from different levels in the namespace hierarchy.
But this is a very welcome step, and I look forward to eventually replacing Vault.
But this is a very welcome step, and I look forward to eventually replacing Vault.
(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.
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
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 :-)
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 :)
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.