OpenBao wants to be the open source secrets manager for self-hosted infrastructure

AWS has Secrets Manager and Microsoft Azure has Key Vault, but companies running their own infrastructure also need a central place to store credentials, keys, and certificates. OpenBao offers an open source alternative for this job, with encrypted storage, temporary credentials, access policies, secret renewal and revocation, and activity logging. The project is governed under OpenSSF within the Linux Foundation.

The key facts about OpenBao in 30 seconds

• OpenBao is an open source secrets manager that started as a fork of HashiCorp Vault.
• It can store secrets, certificates, and keys and encrypt them before storing them.
• It can generate temporary credentials for services such as databases or Kubernetes.
• Secrets can have permissions, expiration, renewal, and revocation policies.
• The project follows community governance under OpenSSF within the Linux Foundation.

The idea behind OpenBao is straightforward: move sensitive information out of configuration files, scattered environment variables, or systems built specifically for individual applications and centralize its management. The project is designed for database credentials, API keys, certificates, and other data that applications and services need to access without keeping them permanently exposed.

Its origins also explain why OpenBao will look familiar to teams that have already worked with Vault. OpenBao began as a fork of HashiCorp Vault and aims to provide an alternative governed by a community under an open source license approved by the Open Source Initiative (OSI). The project is now part of OpenSSF within the Linux Foundation.

More than a vault for passwords

OpenBao is not limited to storing key-value pairs. The system encrypts secrets before writing them to persistent storage, meaning that direct access to the backend where the data is stored does not automatically provide access to the contents of those secrets. It can use different storage backends, including disk and PostgreSQL.

Another important feature is dynamic secrets. Instead of giving an application a permanent credential, OpenBao can generate credentials on demand for supported systems. Its documentation includes Kubernetes and SQL databases among the examples.

Those credentials can be associated with a defined validity period. When the lease expires, OpenBao can automatically revoke them. Clients can also renew leases through the available APIs.

This model changes how credentials are managed. An application can request access when it needs it, use credentials with a limited lifetime, and allow the system to revoke them later. The benefit is not eliminating credentials, but reducing the need to keep them active indefinitely.

OpenBao can also revoke secrets individually or act on entire groups. The project documentation describes, for example, revoking all secrets associated with a user or all secrets of a particular type.

Centralized policies, identities and auditing

In an infrastructure with many services, knowing which application can access each credential can be just as important as storing the secret securely. OpenBao uses authentication and access-control policies to determine which users and applications can access specific resources. It also maintains an audit trail of client activity.

The project is designed as a common layer for managing identities and permissions across environments that may combine different providers and services. Its documentation describes policy-based access control and an identity layer for centralizing access to secrets and other resources.

Another capability is Transit, OpenBao’s encryption-as-a-service system. It allows an application to send data to OpenBao for encryption or decryption without requiring the application itself to store the keys used by OpenBao. The documentation presents this as a way to centralize cryptographic parameters instead of requiring every application to build its own encryption system.

Recent development is taking this functionality further. OpenBao 2.7.0, released on September 23, 2026, added support for external keys through KMS plugins. With this functionality, PKI and Transit engines can perform cryptographic operations using keys backed by external systems, including PKCS#11-compatible modules, without storing the key material inside OpenBao.

A project developing its own direction

OpenBao is no longer simply a copy maintained independently of Vault. Its development is adding its own functionality and a different governance model, while retaining significant compatibility with concepts and APIs inherited from the project it originated from.

Version 2.6, for example, introduced namespace sealing, allowing independent sealing mechanisms to be configured for namespaces, and added KMS plugins for auto-unseal. Version 2.7 continued this direction with external keys for PKI and Transit and support for ML-DSA, the digital signature algorithm standardized by NIST in FIPS 204.

For a technical team, the main difference compared with a managed service from AWS or Azure is where the system runs. OpenBao is designed to be deployed as part of infrastructure controlled by the organization rather than relying exclusively on a cloud provider’s managed secrets service.

That also means taking responsibility for operating the system: deployment, storage, high availability, upgrades, access control, and incident response become part of the team’s responsibilities. Open source does not remove that operational workload.

The project is written in Go and allows the bao binary to be built directly from the repository. It also provides documentation, a web interface, and different deployment mechanisms.

For organizations working with Kubernetes, databases, external APIs, certificates, or multiple infrastructure platforms, OpenBao provides a way to centralize secrets management in an infrastructure layer they control. Its main difference from equivalent services offered by major cloud providers is the control over where it runs and how it is operated.

Frequently asked questions

What is OpenBao?

OpenBao is an open source system for storing and distributing secrets, certificates, and keys. It started as a fork of HashiCorp Vault and is now governed under OpenSSF within the Linux Foundation.

What can OpenBao store?

It can store arbitrary key-value secrets and also work with certificates and keys. Data is encrypted before being written to persistent storage.

Can OpenBao generate temporary passwords?

Yes. OpenBao can generate dynamic credentials for supported systems such as SQL databases or Kubernetes and automatically revoke them when their validity period expires.

Does OpenBao replace AWS Secrets Manager or Azure Key Vault?

It can address a similar secrets-management need, but with a different deployment model. OpenBao is designed to be operated by the organization within its own infrastructure.