[HN Gopher] OpenBao Namespaces
___________________________________________________________________
OpenBao Namespaces
Author : gslin
Score : 80 points
Date : 2025-05-30 03:14 UTC (19 hours ago)
(HTM) web link (openbao.org)
(TXT) w3m dump (openbao.org)
| themk wrote:
| 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.
| p_l wrote:
| From reading, it's explicit choice to add more flexibility to
| namespace controls.
| cipherboy wrote:
| If you have reproducers for behavioral differences, happy to
| take issues and PRs!
|
| (Entities was discussed here: https://github.com/openbao/open
| bao/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.
| p_l wrote:
| 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
| JanMa wrote:
| 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
| cipherboy wrote:
| 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 :-)
| p_l wrote:
| 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 :)
| cipherboy wrote:
| 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.
| sevg wrote:
| OpenBao's development seems heavily reliant on a single person,
| compared to multiple frequent long-term commiters to Vault. Not
| sure if I'd feel comfortable switching from Vault to OpenBao!
|
| I tried linking directly to contributors for last 12 months, but
| you still have to select the time range manually from the
| dropdown :(
|
| OpenBao:
| https://github.com/openbao/openbao/graphs/contributors?from=...
|
| Vault:
| https://github.com/hashicorp/vault/graphs/contributors?from=...
| JanMa wrote:
| It is true that most of the commits in the last 12 months were
| made by cipherboy, but I can assure you that the project is not
| a one man show. Building a community and getting traction on a
| project is hard work and takes time.
|
| Have a look at the contributions for our latest beta release
| and you'll see that the amount of people involved in the
| project is growing:
| https://github.com/openbao/openbao/releases/tag/v2.3.0-beta2...
| sevg wrote:
| Note to clarify: I wasn't intending to disparage the project
| with my original comment! I appreciate that these things take
| time and a lot of hard work. Just wanted to share an
| observation, in the knowledge that it may not hold true
| indefinitely :)
| cipherboy wrote:
| Yes, a big thank you to you, Jan, in particular!
|
| The organization has been slowly building trust in more
| committers and maintainers and so he's had to personally
| review many a pull request of mine in the interim. :-D
| cipherboy wrote:
| GitHub's charts are inaccurate and a quick glance at the commit
| list would tell you that:
| https://github.com/openbao/openbao/commits/main/ -- you have to
| cross some threshhold number of commits across all time in the
| repository to even appear in that dashboard.
|
| https://insights.linuxfoundation.org/project/openbao-2/repos...
| is a more accurate view.
|
| Yes, I contribute a lot, but in the last three months, we've
| seen substantial interest from other groups (thank you SAP,
| Reply, Adfinis, and G-Research OSS to name a few!) and have
| recently promoted a fresh group of committers.
|
| Having worked at HashiCorp, I'm rather proud of what the
| community has built and proud of our ability to promote
| external maintainers. Open governance isn't easy for corporate
| contributions, but it is possible and I thank my employer for
| letting me try. :-)
|
| Just look at the (narrowing) feature gap and critical
| improvements we've landed--transactions to name one--to see why
| I'm optimistic.
| sevg wrote:
| Thanks for the response and calm rebuttal :)
|
| I realise GitHub's graph isn't necessarily fully
| representative, but one personal concern is that I don't know
| yet how long-term many of these new contributors will be.
|
| That said, I also do applaud the efforts to build a
| community-driven fork in a similar vein to OpenTofu (which
| does seem to have critical mass now), and from the sounds of
| what you're saying OpenBao is heading in the right direction
| too.
| burnt-resistor wrote:
| What's annoying is the one man band projects get popular and
| then suddenly deciding to throw it away by archiving it on
| github without giving the chance of others to step in.
| cipherboy wrote:
| Definitely. It's why I've been pushing for open governance
| and slowly building community's trust in additional
| maintainers to avoid burnout and ensure continuity.
|
| You can see maintainer process here:
| https://github.com/openbao/openbao/blob/main/MAINTAINERS.md
|
| And TSC processes here:
| https://github.com/openbao/openbao/blob/main/GOVERNANCE.md
|
| Earlier this month, we moved from LF Edge to OpenSSF to
| better align with our umbrella foundation and hopefully
| reach more people.
| phoronixrly wrote:
| So, the first reflex is to check whether this project offers
| free support/maintenance and development, a.k.a. free labour?
| It goes to show how perverted our current understanding of open
| source is.
| sevg wrote:
| If I understand your comment correctly, I think you've read
| my comment uncharitably.
|
| I'm not making an entitled demand for free labor. I'm talking
| about business decisions.
|
| My business uses many FOSS projects. We want to pick projects
| that are likely to be long-term solutions to reduce churn.
| (We also can't pay for all of them or become committers on
| all of them. Equally, we don't demand free support. This is
| just a risk-based decision making process.)
| 0xbadcafebee wrote:
| Couple of things to consider for your business:
|
| 1) If Vault's license format prevents managed hosted
| solutions, you might want to switch to OpenBao.
|
| 2) Vault has enterprise solutions you have to pay for;
| OpenBao is making those free.
|
| 3) In general, if you plan to pay for support, use Vault.
| If you don't plan to pay for support, use either of them,
| because they require the same amount of maintenance and
| have the same features. Since OpenBao is a fork, you can
| just review the ChangeLogs when you upgrade to see how far
| it has diverged from upstream. Once it's diverged more than
| you're comfortable with, you can just switch back to Vault
| [before you adopt diverged features] and it will be a very
| small change. You can also avoid using any OpenBao features
| which aren't compatible upstream.
|
| It's worth considering that your business can lend
| legitimacy to OpenBao, which will increase its contributor
| share. You can simultaneously make a small, low-risk
| engineering decision, while helping grow an open source
| project [which helps your business].
| cipherboy wrote:
| It is a secrets manager; I think it's a fair question.
|
| Very few individuals will want to run them, the reality is
| they're mostly for businesses to consume. Businesses need
| maintenance reliability and continuity plans and that's why
| I've been pushing on the project's governance aspects for a
| while.
|
| We're not the next TikTok or JS framework so there'll be no
| flash point of popularity. Just have to put in the work and
| see where it goes. :-)
| neximo64 wrote:
| Would be good if it supported AWS
| cipherboy wrote:
| AWS plugins are released separately:
| https://github.com/openbao/openbao-plugins/releases
| p_l wrote:
| yay, somehow I missed the repo and was confusedly waiting for
| plugin catalog :D
| nkotov wrote:
| This is random but it's such a stupid name, right in line with
| OpenTofu.
| yamapikarya wrote:
| does it same as vault namespace? namespace is enterprise feature
| from vault
| cipherboy wrote:
| Yes, implemented from scratch by the community but (mostly--
| barring one reported issue) the same functionality and
| behavior. Not storage-level compatible, we (likely?) made
| different storage layout decisions that I'm rather hopeful will
| set us up nicely for future technical improvements above and
| beyond Vault Enterprise.
___________________________________________________________________
(page generated 2025-05-30 23:01 UTC)