6 ms·

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. :-)

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. :-)