4 ms·

OpenBao Namespaces

89 points by gslin 1y ago

themk 1y ago
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 1y ago
  From reading, it's explicit choice to add more flexibility to namespace controls.
  - cipherboy 1y ago
    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-2918288906 https://github.com/openbao/openbao/issues/1110#issuecomment-...) Right, check out our vision post as well: https://openbao.org/blog/vision-for-namespaces/ 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 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 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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 1y ago
        You should read this RFC: https://github.com/openbao/openbao/issues/1340 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 1y ago
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=25%2F05%2F2024 https://github.com/openbao/openbao/graphs/contributors?from=... Vault: https://github.com/hashicorp/vault/graphs/contributors?from=25%2F05%2F2024 https://github.com/hashicorp/vault/graphs/contributors?from=...
- JanMa 1y ago
  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-beta20250528 https://github.com/openbao/openbao/releases/tag/v2.3.0-beta2...
  - sevg 1y ago
    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 1y ago
    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 1y ago
  GitHub's charts are inaccurate and a quick glance at the commit list would tell you that: https://github.com/openbao/openbao/commits/main/ 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/repository/openbao-openbao/contributors 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.
neximo64 1y ago
Would be good if it supported AWS
- cipherboy 1y ago
  AWS plugins are released separately: https://github.com/openbao/openbao-plugins/releases https://github.com/openbao/openbao-plugins/releases
  - p_l 1y ago
    yay, somehow I missed the repo and was confusedly waiting for plugin catalog :D
nkotov 1y ago
This is random but it's such a stupid name, right in line with OpenTofu.
- deleted 1y ago
  [deleted]
yamapikarya 1y ago
does it same as vault namespace? namespace is enterprise feature from vault
- cipherboy 1y ago
  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.
  - yamapikarya 1y ago
    are you planning to add all of the enterprise features from vault to openbao? btw thank you very much for your effort!!!
    - cipherboy 1y ago
      Not without community involvement :-) Horizontal scalability and disaster recovery is one of the next larger features on our mind. We won't use the architecture of Performance Secondaries, and likely will transparently upgrade (existing) Standby nodes to become read-scalable. Local storage is interesting, but brings with it additional complexity that few need. Better to use namespaces with distinct storage backends (distributing active across all nodes in a cluster) to scale writes horizontally across different namespaces before looking at horizontal scalability of a single mount (which is all that local storage gives you -- it doesn't give you write scalability across namespaces). Also on that list is external key support, similar to managed keys from Vault Enterprise, but with different configuration semantics: https://github.com/openbao/openbao/pull/1320 https://github.com/openbao/openbao/pull/1320 We currently have no plans for implementing some of the enterprise secrets bcakends (KMIP, Transform/Tokenization, KMSE, ...) though of course would be welcoming to these as well. Sync is another area that is not in the cards for the short-term. In terms of differentiation, we have a lot of unique RFCs in-flight that I presume are not on Vault Enterprise's immediate roadmap: - https://github.com/openbao/openbao/pull/1365 https://github.com/openbao/openbao/pull/1365 -- starting plans for a UI rewrite and high-level feature requirements - https://github.com/openbao/openbao/pull/1357 https://github.com/openbao/openbao/pull/1357 -- per-namespace seal mechanisms - https://github.com/openbao/openbao/issues/769 https://github.com/openbao/openbao/issues/769 -- Restrict LIST+SCAN (recursive) to only accessible entries - https://github.com/openbao/openbao/pull/1304 https://github.com/openbao/openbao/pull/1304 -- static key auto-unseal, to aid chaining in trusted environments - https://github.com/openbao/openbao/pull/1341 https://github.com/openbao/openbao/pull/1341 -- declarative one-time self-initialization to aid setup - https://github.com/openbao/openbao/pull/1302 https://github.com/openbao/openbao/pull/1302 -- inline authentication rather than existing ahead-of-time token-based authentication and probably more I'm missing. Feel free to reach out if you want to discuss more or contribute in any way -- we welcome more than just code contributions, there's many ways one can help. :-)

89 points by gslin 1y ago

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 1y ago
From reading, it's explicit choice to add more flexibility to namespace controls.
- cipherboy 1y ago
  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-2918288906 https://github.com/openbao/openbao/issues/1110#issuecomment-...) Right, check out our vision post as well: https://openbao.org/blog/vision-for-namespaces/ 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 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 1y ago
    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 1y ago
      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 1y ago
      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 1y ago
        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 1y ago
        You should read this RFC: https://github.com/openbao/openbao/issues/1340 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 1y ago

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=25%2F05%2F2024 https://github.com/openbao/openbao/graphs/contributors?from=... Vault: https://github.com/hashicorp/vault/graphs/contributors?from=25%2F05%2F2024 https://github.com/hashicorp/vault/graphs/contributors?from=...

JanMa 1y ago
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-beta20250528 https://github.com/openbao/openbao/releases/tag/v2.3.0-beta2...
- sevg 1y ago
  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 1y ago
  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 1y ago
GitHub's charts are inaccurate and a quick glance at the commit list would tell you that: https://github.com/openbao/openbao/commits/main/ 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/repository/openbao-openbao/contributors 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.

neximo64 1y ago

Would be good if it supported AWS

cipherboy 1y ago
AWS plugins are released separately: https://github.com/openbao/openbao-plugins/releases https://github.com/openbao/openbao-plugins/releases
- p_l 1y ago
  yay, somehow I missed the repo and was confusedly waiting for plugin catalog :D

nkotov 1y ago

This is random but it's such a stupid name, right in line with OpenTofu.

deleted 1y ago
[deleted]

yamapikarya 1y ago

does it same as vault namespace? namespace is enterprise feature from vault

cipherboy 1y ago
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.
- yamapikarya 1y ago
  are you planning to add all of the enterprise features from vault to openbao? btw thank you very much for your effort!!!
  - cipherboy 1y ago
    Not without community involvement :-) Horizontal scalability and disaster recovery is one of the next larger features on our mind. We won't use the architecture of Performance Secondaries, and likely will transparently upgrade (existing) Standby nodes to become read-scalable. Local storage is interesting, but brings with it additional complexity that few need. Better to use namespaces with distinct storage backends (distributing active across all nodes in a cluster) to scale writes horizontally across different namespaces before looking at horizontal scalability of a single mount (which is all that local storage gives you -- it doesn't give you write scalability across namespaces). Also on that list is external key support, similar to managed keys from Vault Enterprise, but with different configuration semantics: https://github.com/openbao/openbao/pull/1320 https://github.com/openbao/openbao/pull/1320 We currently have no plans for implementing some of the enterprise secrets bcakends (KMIP, Transform/Tokenization, KMSE, ...) though of course would be welcoming to these as well. Sync is another area that is not in the cards for the short-term. In terms of differentiation, we have a lot of unique RFCs in-flight that I presume are not on Vault Enterprise's immediate roadmap: - https://github.com/openbao/openbao/pull/1365 https://github.com/openbao/openbao/pull/1365 -- starting plans for a UI rewrite and high-level feature requirements - https://github.com/openbao/openbao/pull/1357 https://github.com/openbao/openbao/pull/1357 -- per-namespace seal mechanisms - https://github.com/openbao/openbao/issues/769 https://github.com/openbao/openbao/issues/769 -- Restrict LIST+SCAN (recursive) to only accessible entries - https://github.com/openbao/openbao/pull/1304 https://github.com/openbao/openbao/pull/1304 -- static key auto-unseal, to aid chaining in trusted environments - https://github.com/openbao/openbao/pull/1341 https://github.com/openbao/openbao/pull/1341 -- declarative one-time self-initialization to aid setup - https://github.com/openbao/openbao/pull/1302 https://github.com/openbao/openbao/pull/1302 -- inline authentication rather than existing ahead-of-time token-based authentication and probably more I'm missing. Feel free to reach out if you want to discuss more or contribute in any way -- we welcome more than just code contributions, there's many ways one can help. :-)