OpenBao Direction Proposal

This proposes a high level direction for the OpenBao project, suggesting features that contributors could work on that would be well-received by the project and its users. This document proposes features fitting the follow high-level categories:

1. "Safer": to enable safer operation of OpenBao, through transactions, break-glass procedures, and improved ACL and audit capabilities ,
2. "Community": to encourage community maintainership of external plugins and client libraries, and
3. "Scalability": to improve scalability of the core, through reducing resource consumption and removing design limitations.

This proposal was developed by the OpenBao Dev WG and approved by the TSC.

GitLab-driven features

I'd like to express interest in tackling the following topics.

1. Continued investment in transactional storage. (safer)
2. Contributing a Ruby OpenAPI client to the community, to help drive improvements to our OpenAPI generated specs and encourge collaboration in other languages. (community)
3. Splitting the mount table to remove a scaling limitation of OpenBao. (scalability)
4. Support automatic cleanup of long-unused (forgotten) ACL policies, to prevent later malicious usage. (safer)
5. Develop parallel unseal capabilities, including Shamir's, for break-glass recovery procedure in the event of deleted or non-responsive KMS keys. (safer)
6. Develop a GitLab Secrets Engine, to create all types of access tokens, including personal and group not supported by this plugin. (community)

These are subject to change and with no expressed timeline, likely spread across several releases, though many are currently in-progress.

Community-developed core features

We'd like to encourage new or continued interest in the following features that broadly align with our stated directional goals.

1. @DanGhita has expressed interest in the revival of the Postgres backend and contributing transactional support to it. (safer)
2. @JanMa has expressed interest in building and integrating a plugin registry to OpenBao, similar to OpenTofu's. This will greatly help manage external plugins, bringing near-builtin experience. (community).
3. @jsmoon-openerd has started PKCS#11 HSM support in go-kms-wrapping to enable HSM-based auto-unseal. (safer).
4. Allow HA standby nodes to service read-only (from a storage modification PoV) requests. (scalability)
   • Currently HA mode standby nodes forward all requests up to the active node, preventing horizontal scalability of OpenBao. Due to limitations in Raft (only the active node can perform storage writes), we can't immediately scale writes. Thus, start by bringing these nodes "online" (loading the mount table, plugins, &c) and allowing them to service read-only requests, returning ErrReadOnly on storage write operations to trigger automatic request forwarding.
   • @cipherboy is happy to collaborate or author the RFC design document for this if someone wants to tackle it.
5. Namespace support. (safer)
   • Vault Enterprise supports Namespaces to grant tenant-segmented portions of the URL space. After adopting this feature, we can take alternative design approaches, like allowing per-namespace (parallel-)unseal mechanisms with separate barrier keyrings, tenant-local plugin multiplexing, and other changes to improve the safety and scalabililty of the feature.
6. Reviving the OpenBao UI. (community)
7. Extending usage of paginated lists. (scalability)
8. Extending usage of transactions. (safer)
9. Improvements to auditing. (safer)
10. Programatic ACL creation, using hclwrite to modify OpenBao-created ACLs. (safer)
    • By using a URL structure like /sys/policies/acl/:name/grants/:path/capabilities/:cap and in conjunction with Namespaces, users could be granted limited ACL policy creation capabilities.
11. Extensions to the ACL templating system, perhaps optionally using text/template or extending the existing templating system, particularly to support complex metadata typing. (safer)
    • OpenBao's metadata field (on tokens and entities) are only allowed to map from string->string; while sufficient for many use cases, allowing complex string->[]string or string->interface{} data and letting the ACL system iterate over these structures would let external authorization systems have more (but, still, limited by the ACL system) control over policies. Presently each granted path (with templates) would need to use separate source metadata fields, also affecting scalability of this system.
12. Extending OpenBao's usage of go-kms-wrapping to support external wrapper plugins. (scalability)
    • This would let us independently version and release independent wrappers, allow users to author their own KMS plugins, integrate with the registry, and reduce the core binary size with a one-time config-level breaking change (to use an external plugin after deprecating and removing the built-in wrappers -- all while preserving the use of the original unseal keys).
13. Ensure all builtin plugins can be used externally in preparation for the registry. (community)
14. Allow external audit plugins for parity with auth and secret plugins. (community)
15. Allow external storage plugins (Feature Request: Support for mysql storage backend #651) for parity with auth and secrets plugins. (community)
16. Add automatic Raft Snapshots, a Vault Enterprise feature requested by @JanMa. (safer)
17. Automatic TLS Listener certificates via ACME. (safer)
18. Allowing ACL policies to operate under union principles. (safer)
19. Post-Quantum Cryptography. (safer)

We welcome any contributions in these or other areas, big or small!

External plugin revivals

Additionally, we'd like to encourage shared community maintainership and improvements to the following critical plugins:

1. GCP Auth
2. GCP Secret
3. AWS Auth
4. AWS Secret
5. Redis ValKey Plugin

Non-code changes

We'd also like to encourage non-technical, community-lead improvements in the following areas:

1. Writing tutorials for administrators and integrating developers.
2. Expanding developer documentation for understanding the architectural layout of the OpenBao core code.
3. Expanding developer documentation for plugin authoring.
4. Improving the overall OpenBao community documentation, such as changes suggested by @IohannesArnold.

Reaching out

If anyone has questions about getting started or collaborating, reach out on Matrix, the mailing list, or GitHub discussions.