secure k8 s

OpenBao

Summary: OpenBao is an open-source, community-driven fork of HashiCorp Vault that provides identity-based secrets management — storing, generating, encrypting, and revoking secrets behind an authenticated API. It now lives under the OpenSSF umbrella.

Sources: raw/docs/internals/architecture.md, raw/docs/concepts/*, raw/blog/2024-07-25-release-v2-0-0.md, raw/blog/2025-06-17-openbao-to-openssf.md, raw/blog/2025-10-20-roadmap-2.0.md.

Last updated: 2026-05-19

What it is

OpenBao is a secrets-management server. Clients authenticate against it, receive a token, and use that token to read or generate secrets from one of many secrets engines. Every request is logged, every secret is leased and revocable, and all on-disk data is encrypted by a barrier whose root key is itself protected by an unseal mechanism (source: raw/docs/internals/architecture.md).

The system is organized around mountable components:

  • auth methods — verify who a client is.
  • secrets engines — store, generate, or encrypt data.
  • audit devices — log every request/response.
  • plugins — auth, secret, and database backends, built-in or external.

These all hang off paths in a single namespace (auth/..., kv/..., pki/..., etc.), and policies grant access path by path (source: raw/docs/concepts/policies.md).

How a request flows

  1. Client authenticates against an auth method → gets a token.
  2. Token has policies attached → grants/denies access to paths.
  3. Client calls a path; the router dispatches to a secrets engine or system endpoint.
  4. Response goes through the audit log on the way out.
  5. If the response is a dynamic credential, it carries a lease that OpenBao will eventually revoke.

Architecture in one paragraph

The encryption layer (the barrier) sits between OpenBao core and the storage backend; storage is treated as untrusted (source: raw/docs/internals/architecture.md). On startup OpenBao is in a sealed state — it cannot decrypt the keyring until enough unseal-key shares are provided (or an auto-unseal KMS supplies the root key). Once unsealed, the audit devices, auth methods, and secrets engines configured in the mount tables are loaded and the server begins serving requests. For HA, one node holds a lock in the storage backend and becomes active; others stand by and forward or redirect.

The fork story

OpenBao was forked from HashiCorp Vault in 2024 after Vault’s license change. v2.0.0 was the initial GA release in July 2024 (source: raw/blog/2024-07-25-release-v2-0-0.md). In June 2025 OpenBao moved into the OpenSSF (source: raw/blog/2025-06-17-openbao-to-openssf.md). The 2025–2026 roadmap focuses on namespaces, horizontal scalability, and a 2.0 platform refresh (source: raw/blog/2025-10-20-roadmap-2.0.md).

See blog-timeline for the full release/event timeline.

What’s distinctive vs upstream Vault

  • Native namespaces in OSS (announced 2025-05-30) — multi-tenancy is not an enterprise-only feature here (source: raw/blog/2025-05-30-namespaces-announcement.md).
  • Transactional storage primitives in the Raft backend (source: raw/blog/2024-10-27-transaction-details.md).
  • Horizontal scalability work: v2.5.0 lets standby nodes serve reads (source: raw/blog/2026-03-25-improved-horizontal-scalabilty.md).
  • Open governance via Maintainers/Committers/Moderators model (source: raw/blog/2024-10-03-maintainers.md).