Open-source secrets management, encryption-as-a-service, and PKI. Linux Foundation fork of HashiCorp Vault, forked at the BSL transition (Vault 1.14) and continuing under MPL-2.0.
OpenBao is the Linux Foundation OSS continuation of HashiCorp Vault, forked at Vault 1.14 just before the August 2023 BSL transition. It's the canonical OSS path for organizations that need Vault's secrets management, encryption-as-a-service, and PKI capabilities without committing to BSL licensing terms. Functionally identical to its Vault parent at the fork point; production maturity is still building (LF accepted Dec 2024) but momentum is strong with backers including IBM, GitLab, and Roblox.
OpenBao's defining trust property is **license predictability**. Vault's August 2023 BSL transition retroactively made its 'OSS' label inaccurate for years, and many organizations only realized their compliance exposure when external reviewers flagged it. OpenBao is the alternative whose license cannot change unilaterally — it's MPL-2.0 under Linux Foundation governance, the same arrangement that protects Kubernetes, CNCF projects, and dozens of other infrastructure foundations. Choosing OpenBao over Vault for new deployments is choosing predictability over momentum: you give up some operational tooling maturity (HCP Vault's managed service has no OpenBao equivalent yet) in exchange for a compliance posture that won't change overnight.
Same engine as Vault 1.14. Sub-100ms KV read/write, sub-second cluster operations, sub-200ms PKI signing. Cap rule N/A (cold starts under 5s). Performance characteristics are unchanged from Vault since this is a hard fork at the source level.
Policy DSL (HCL) and CLI/API are precise and well-documented but not natural language. Cap rule N/A — HCL is structured config, not a 'proprietary query language' in the methodology sense, but the score reflects that it's not natural either. Operators write policies in HCL; agents make REST API calls.
Full RBAC via policies, ABAC via templated policies and entity metadata, comprehensive audit logs (file, syslog, socket sinks). Cap rule N/A. Vault's permission model is the gold standard for secrets management; OpenBao inherits this verbatim.
Multi-cloud, multi-deployment, no vendor lock-in (MPL-2.0). Same as Vault at the fork point. Storage backends include Raft (built-in), Consul, etcd, S3, GCS, Azure. Cap rule N/A.
Many secret backends: KV v1/v2, database (Postgres, MySQL, MongoDB, etc.), PKI, transit encryption, SSH, AWS/Azure/GCP cloud auth, Kubernetes auth. Audit log forwarding to multiple destinations. Cap rule N/A — has logical decoding-equivalent through audit log streaming.
Comprehensive audit logs with full request/response capture (sensitive fields hashed). Lease tracking provides full lifecycle visibility. Cap rule N/A — cost-per-query attribution is not applicable to secrets management; the methodology cap is for cost transparency, not query metrics in general.
G1=Y (sub-10ms ABAC via templated policies with indexed entity metadata), G2=Y (audit logs cover 100% of access paths), G3=Y (lease-based approval workflows; tokens can be issued with revocation hooks for HITL), G4=Y (config versioning via Git/HCL is standard), G5=Y (well-documented threat model inherited from Vault), G6=Y (compliance mapping in deployment guides covers HIPAA, FedRAMP, SOC 2 deployment patterns). 6/6 yes -> 5.
O1=Y (telemetry endpoint exposes Prometheus metrics), O2=Y (OpenTelemetry support for distributed tracing), O3=N (no per-query cost attribution — N/A for secrets management, but the question asks Yes/No literally), O4=Y (MTTD under 10 min with proper monitoring stack: Prometheus + Grafana + alerting), O5=N (no drift detection in product — that's an external tool's job), O6=N (not an AI decisioning system, no explainability surface). 4/6 -> 4.
A1=Y (sub-2s p95 for KV reads, signing, leasing), A2=Y (real-time secret retrieval, no batch lag), A3=Y (lease caching reduces repeated upstream auth calls), A4=Y (HA cluster with Raft achieves 99.9%+ uptime when properly deployed), A5=N (rarely load-tested at 10x by most teams — capacity planning is operational), A6=Y (parallel batch operations supported via API). 5/6 -> 4.
L1=Y (path-based entity organization functions as entity resolution; lenient interpretation per vendor-lens guidance), L2=Y (secret namespacing and entity metadata serves as a domain glossary; lenient), L3=N (no disambiguation logic — agents either know the path or get 404), L4=N (no continuous learning from access patterns), L5=Y (path namespacing is canonical terminology alignment across services), L6=Y (audit log review by humans is standard practice). 4/6 -> 4.
S1=Y (deterministic secret retrieval — every read returns the same value or version), S2=Y (typed secrets with no missing fields by design), S3=Y (consistent across HA replicas via Raft consensus), S4=Y (schema-enforced secret types via path conventions), S5=Y (3-stage data quality: policy enforcement at ingress + audit at storage + lease validation at retrieval), S6=Y (lease/token anomaly detection via audit log analysis). 6/6 -> 5.
Best suited for
Compliance certifications
OpenBao the project does not hold compliance certifications. Compliance comes from how you deploy it: self-hosted on FedRAMP-authorized infrastructure (AWS GovCloud, Azure Gov), HIPAA-compliant deployments using a BAA-signing cloud provider, SOC 2 attestation through your overall stack audit. The LF project doesn't sign BAAs or hold third-party audit reports. As OpenBao matures, expect managed-service deployments (similar to how RDS provides managed Postgres with HIPAA BAAs) — none widely available yet.
Use with caution for
Choose Vault when you need HCP Vault's managed service, Vault Enterprise's Sentinel policy engine, namespaces for multi-tenancy, or replication for active-active across regions. OpenBao wins on license predictability and is functionally identical at the fork point — but Vault has the managed offering and the Enterprise-tier features that OpenBao doesn't yet match.
View analysis →Choose AWS Secrets Manager when you're an AWS-native shop, want zero operational overhead, and don't need cross-cloud portability. OpenBao wins on multi-cloud flexibility and avoiding AWS lock-in, but AWS Secrets Manager wins on simplicity, native integration with IAM/KMS, and the absence of any cluster operations to manage.
View analysis →Choose Azure Key Vault for Azure-stack deployments wanting tight integration with Azure AD/Entra and Microsoft compliance certifications. OpenBao wins on cross-cloud portability and OSS license posture, but Azure Key Vault wins on out-of-box FIPS 140-2, HSM-backed keys, and zero operational burden inside Azure environments.
View analysis →Role: L5 secrets management substrate — provides KV secrets, dynamic database credentials, encryption-as-a-service, PKI certificate issuance, and SSH credential brokering for agent stacks.
Upstream: Receives secret writes from CI/CD (Terraform, GitOps), security teams (manual rotation), cloud auth assertions (AWS IAM, Azure MSI). Configuration via HCL files in version control.
Downstream: Issues secrets to L4 agents via API, dynamic database credentials to L1 stores, service certs to L7 mesh, audit logs to L6 observability stack.
Mitigation: Audit current Vault usage for Enterprise-only features before committing to OpenBao migration. Use `vault read sys/license` to confirm Community Edition equivalents. If Enterprise features are in use, plan a separate evaluation of whether the use case can be redesigned without them.
Mitigation: Deploy with at least 3 nodes using integrated Raft storage (or Consul backend). Configure auto-unseal via cloud KMS so cluster recovery doesn't require human intervention. Test failover with a planned reboot and measure RTO.
Mitigation: Enable audit logs at session level. Stream logs to centralized storage (CloudWatch, Datadog, Splunk) immediately, not just local disk. Verify audit log durability after a planned restart. Most compliance frameworks (SOC 2, FedRAMP) require this.
Mitigation: OpenBao is self-hosted only today. If your team can't operate stateful HA infrastructure, either stay on HCP Vault (BSL but managed) or pick a managed cloud secrets service (AWS Secrets Manager, Azure Key Vault). Don't run OpenBao without operational expertise.
Database secrets engine generates dynamic Postgres credentials with 30-minute leases. Audit logs satisfy HIPAA access logging requirements when deployed via a BAA-signing cloud provider. PKI engine issues service-to-service certs for clinical-data agents.
Single OpenBao cluster federates secrets across all three. Cloud-specific auth methods (AWS IAM, Azure MSI, GCP IAM) let workloads in each cloud authenticate without static credentials. Avoids per-cloud secrets-manager lock-in.
OpenBao is overkill if you're AWS-only and have one or two services. AWS Secrets Manager is simpler. Choose OpenBao when you anticipate multi-cloud growth or strict OSS license requirements.
OpenBao doesn't have Sentinel or namespaces. If your existing Vault deployment relies on these, migration to OpenBao requires architectural rework. Evaluate whether you can redesign without them, otherwise stay on Vault Enterprise or evaluate alternative stacks.
This analysis is AI-generated using the INPACT and GOALS frameworks from "Trust Before Intelligence." Scores and assessments are algorithmic and may not reflect the vendor's complete capabilities. Always validate with your own evaluation.