OpenBao vs. HashiCorp Vault: Production Secrets Migration, Raft Latency Benchmarks & Enterprise TCO

# OpenBao vs HashiCorp Vault Migration: Production Secrets, Raft Latency Benchmarks & Enterprise TCO

Summary: Migrating from HashiCorp Vault to Linux Foundation OpenBao provides an open-source secrets management migration path for Vault 1.14.x deployments, retaining wire-protocol API compatibility, cryptographic barrier mechanics, and Integrated Raft storage performance without commercial licensing overhead. This comprehensive production guide details pre-flight compatibility boundaries, zero-downtime Raft snapshot restoration, automated AWS KMS unsealing, dual-AZ quorum architecture, dynamic secrets integration, and an illustrative multi-year enterprise TCO model.

---

The Secrets Management Watershed: BSL Licensing, Fork Origins, and Governance

For nearly a decade, HashiCorp Vault served as the de facto control plane for machine identity, dynamic database credential issuance, and software envelope encryption. Enterprise platform engineering teams anchored their security perimeters around Vault's unified API, relying on its battle-tested access control lists (ACLs) and pluggable storage backends.

However, HashiCorp's August 2023 relicensing announcement transitioned Vault from the Mozilla Public License v2.0 (MPLv2) to the Business Source License (BSL 1.1) for subsequent releases. This change restricted commercial derivative competition by prohibiting competitive production offerings based on BSL-licensed code. The transition prompted enterprise compliance, security, and procurement teams to scrutinize software supply chains, evaluate vendor lock-in risks, and assess long-term commercial software budgeting. Following IBM's agreement to acquire HashiCorp in April 2024, enterprise organizations have placed increased emphasis on open governance, licensing predictability, and transparent long-term support.

HashiCorp BSL License Shift and the Linux Foundation Mandate

In direct response to the BSL transition, open-source community contributors, cloud providers, and enterprise stakeholders coalesced under the Linux Foundation in December 2023 to establish OpenBao. OpenBao operates under an open governance model, guaranteed perpetual MPLv2 licensing, and neutral steward oversight.

Crucially, OpenBao forked strictly from HashiCorp Vault version 1.14.8—the final stable release distributed under MPLv2 before the BSL cutover. Vault 1.15.0 was released under BSL 1.1 and did not contribute code to the initial OpenBao codebase.

Unlike downstream vendor distributions that inject proprietary telemetry or closed-source enterprise modules, OpenBao operates under a community-governed mandate:

1. Neutral Governance: Technical direction and releases are steered by a Technical Oversight Committee (TOC) representing multiple independent organizations under the Linux Foundation.

2. Perpetual Permissive Licensing: Retaining MPLv2 ensures that organizations can deploy, modify, and integrate OpenBao within commercial software platforms without violating BSL restrictions, provided modifications to MPLv2-covered files remain open source.

3. Core Feature Parity: Critical capabilities historically gated behind commercial paywalls—including automated operational ergonomics, extended cryptographic algorithms, and path-based tenant isolation patterns—are developed openly within the community mainline.

API and Storage Parity Boundary: Vault 1.14/1.15 vs. OpenBao 2.x

A primary engineering concern during an openbao vs hashicorp vault migration is API and client SDK compatibility. OpenBao preserves full wire-protocol compatibility with the Vault HTTP API (/v1/*). Existing API tokens, cryptographic paths, policy rule definitions, and client SDKs (including HashiCorp Go vault/api, Python hvac, Java Spring Cloud Vault, and Kubernetes CSI Secret Store drivers) interact with OpenBao endpoints without requiring application codebase rewrites.

At the storage layer, understanding the exact version boundary is critical for a successful migration:

• Vault 1.14.x Open Source (CE): OpenBao retains binary storage compatibility with the Integrated Storage (Raft) engine and underlying BoltDB (bbolt) transactional key-value store used in Vault 1.14.x CE. Both systems encrypt key-value entries, lease metadata, and token indexes using an identical 256-bit AES-GCM or ChaCha20-Poly1305 master key derived during cluster unsealing. Consequently, Raft snapshots exported from Vault 1.14.x CE can be restored directly into OpenBao clusters, and in-place binary upgrades from 1.14.8 to OpenBao 2.x are supported.
• Vault 1.15.0+ (BSL): Starting with Vault 1.15.0, internal storage schema modifications and metadata structures were introduced. According to official OpenBao project documentation, direct raw Raft snapshot ingestion from Vault 1.15+ into OpenBao is not supported. Migrations originating from Vault 1.15.0 or later require API-driven logical migration workflows (such as exporting secrets, policies, and auth roles via HTTP API pipelines) rather than raw block-level Raft snapshot restoration.
• Vault Enterprise Clusters: Proprietary features in Vault Enterprise—such as Enterprise Namespaces, Sentinel policies, and Performance Replication—embed proprietary metadata within the Raft log. Direct raw snapshot ingestion from Vault Enterprise into OpenBao is not supported without first decoupling or exporting data from those proprietary features into standard path hierarchies.

---

Production Benchmark Matrix: 10,000 RPS Load on Integrated Raft Storage

To validate how OpenBao performs under heavy enterprise production stress, we examine a reproducible synthetic performance benchmark specification. Because OpenBao 2.x and Vault 1.14.x share the same core Go Integrated Raft consensus engine and cryptographic barrier architecture, their steady-state throughput and latency characteristics align closely under equivalent hardware and network configurations.

Test Rig Architecture and Load Generation Methodology

The reference benchmark environment simulates a high-throughput, zero-trust cloud deployment:

• Compute Nodes: 3x AWS c6i.2xlarge instances (8 vCPUs, Intel Xeon 8375C @ 3.5 GHz, 16 GiB DDR4 RAM).
• Storage Subsystem: Dedicated Amazon EBS io2 volumes (100 GiB, provisioned 3,000 IOPS, 16 KiB block size, average queue depth $\le 2$).
• Network Fabric: Single AWS Availability Zone with 12.5 Gbps enhanced networking (sub-0.2ms inter-node latency).
• Operating System: Ubuntu 24.04 LTS running Linux kernel 6.8 with tuned networking parameters:

* net.core.somaxconn = 65535

* net.ipv4.tcp_max_syn_backlog = 32768

* fs.file-max = 2097152

• Load Generators: 3x distributed c6i.4xlarge worker nodes executing ghz and custom Go HTTP client harnesses across a dedicated VPC subnet, generating 10,000 requests per second (RPS) sustained over 60 minutes.

The test suite executed a balanced enterprise workload mix:

• 60% KV-v2 Secret Reads: Authenticated lookups against /v1/secret/data/production/services/* (1 KiB payload).
• 10% KV-v2 Secret Writes: High-churn versioned writes generating transactional Raft log commits.
• 15% Kubernetes ServiceAccount Logins: JWT token verification against /v1/auth/kubernetes/login with dynamic token generation.
• 10% AppRole Authentications: Role ID and Secret ID validation against /v1/auth/approle/login.
• 5% Transit Cryptographic Decryptions: Symmetric batch decryption using 256-bit AES-GCM envelope keys.

High-Throughput Latency and Resource Utilization Matrix

The following matrix documents representative telemetry collected during a 10,000 RPS sustained synthetic test run, comparing an open-source HashiCorp Vault 1.14.8 baseline against Linux Foundation OpenBao 2.1.0 on identical infrastructure:

Note: Telemetry reflects synthetic test runs using standardized load generators on provisioned AWS io2 storage. In real-world enterprise deployments, actual throughput and latency vary according to hardware specs, network topology, storage IOPS, and dynamic secrets engine backends.

Raft Consensus Internals: FSM Serialization, Fsync Overhead, and Tail Latency

Analyzing the consensus and storage mechanics illustrates why OpenBao demonstrates performance parity with open-source Vault:

1. Finite State Machine (FSM) Lock Contention: Every transactional mutation (write, lease revocation, token issuance) must serialize through the Raft leader's state machine. Cached reads bypass the state machine once valid read-locks are established, maintaining sub-millisecond response times even under heavy concurrent load.

2. Storage I/O and Fsync Frequency: In Raft consensus, a state write is acknowledged only after a quorum of voting nodes flushes the entry to persistent storage via fsync(2). With io2 storage provisioned at 3,000 IOPS, individual fsync operations typically complete within 0.5 to 0.8 ms, establishing disk write latency as the primary physical bound on write throughput.

3. Go Runtime and Concurrency Handling: OpenBao is compiled against modern Go toolchains (Go 1.22+), benefiting from runtime improvements in garbage collection pacing and memory allocation efficiency. Under sustained concurrency, memory usage remains stable, avoiding significant pause spikes during high-volume authentication churn.

---

Architecture Blueprint: Multi-AZ Quorum and Performance Standby Topology

Deploying OpenBao in production requires a resilient distributed design. Secrets management engines cannot afford downtime during an availability zone outage or host failure.

Quorum Mechanics Across Dual Availability Zones

A common challenge in cloud environments is architecting resilient high availability across two primary compute availability zones (AZ-a and AZ-b). Raft consensus requires a strict majority of voting members:

$$\text{Quorum} = \left\lfloor \frac{N}{2} \right\rfloor + 1$$

For a 3-node cluster ($N=3$), quorum is 2. If an enterprise places two nodes in AZ-a and one node in AZ-b, an outage of AZ-a causes the cluster to lose quorum, entering an unsealed read-only or offline state.

To solve this, our production architecture deploys:

• Node 1 (Active Leader): Located in AZ-a, serving reads and processing all transactional writes.
• Node 2 (Performance Standby): Located in AZ-b, maintaining an in-sync Raft log replica, serving local read requests directly without forwarding them to the leader, and assuming leadership instantaneously upon leader failure.
• Node 3 (Voting Arbiter): Located in AZ-c (or a lightweight tie-breaker instance in a third zone) to maintain a 3-node voting quorum without requiring duplicate heavy compute in a third data center.
• Automated Cloud KMS Barrier: AWS KMS Key (or HashiCorp/OpenBao Transit seal) shared across availability zones to execute automated unseal and key-wrapping operations.

High Availability Cluster Topology Diagram

The following diagram illustrates client traffic routing, Raft gRPC replication streams, and automated unseal integration across the availability zones:

flowchart TD
    subgraph Clients["Client Workload Layer"]
        K8s["Kubernetes Workloads / Apps"]
        CI["CI/CD Pipelines & Microservices"]
    end

    subgraph LB["Traffic Distribution"]
        NLB["AWS Network Load Balancer (mTLS Port 8200)"]
    end

    subgraph AZ_A["Availability Zone A (Primary)"]
        NodeA["OpenBao Node 1\n(Active Leader)\nHTTP :8200 | Raft :8201"]
        EBS_A[("io2 Storage Volume\nBoltDB Raft Log")]
    end

    subgraph AZ_B["Availability Zone B (Secondary)"]
        NodeB["OpenBao Node 2\n(Performance Standby)\nHTTP :8200 | Raft :8201"]
        EBS_B[("io2 Storage Volume\nBoltDB Raft Log")]
    end

    subgraph AZ_C["Availability Zone C (Witness)"]
        NodeC["OpenBao Node 3\n(Voting Arbiter)\nHTTP :8200 | Raft :8201"]
        EBS_C[("io2 Storage Volume\nBoltDB Raft Log")]
    end

    subgraph KMS["Automated Unseal Barrier"]
        AWSKMS["AWS KMS Key (Customer Managed Key)\nEnvelope Encryption (AES-256)"]
    end

    Clients -->|HTTPS API Requests| NLB
    NLB -->|Health Check: /v1/sys/health| NodeA
    NLB -.->|Standby Read Routing| NodeB

    NodeA <===>|gRPC Raft Replication :8201| NodeB
    NodeA <===>|gRPC Consensus Heartbeat :8201| NodeC
    NodeB <===>|gRPC Consensus Heartbeat :8201| NodeC

    NodeA --- EBS_A
    NodeB --- EBS_B
    NodeC --- EBS_C

    NodeA -.->|kms:Decrypt / kms:Encrypt| AWSKMS
    NodeB -.->|kms:Decrypt / kms:Encrypt| AWSKMS
    NodeC -.->|kms:Decrypt / kms:Encrypt| AWSKMS

In this architecture, client traffic arrives at an AWS Network Load Balancer. The NLB evaluates /v1/sys/health endpoints:

• Active Node (Node 1) returns HTTP 200 OK.
• Performance Standby (Node 2) returns HTTP 429 (default for standby) or HTTP 200 if configured to serve local reads (performance_standby_node_count > 0).
• Writes received by the performance standby are forwarded internally over mTLS to the active leader via port 8201.

---

Complete OpenBao Server Configuration with Automated Unseal

Below is a complete, production-hardened openbao.hcl configuration for an enterprise node using Integrated Raft storage and AWS KMS automated unseal.

Production-Hardened HCL Configuration

# /etc/openbao.d/openbao.hcl
# Production High-Availability Configuration for OpenBao

ui            = true
disable_mlock = false # Enforce memory locking to prevent secrets swapping to disk

storage "raft" {
  path    = "/var/lib/openbao/data"
  node_id = "bao-node-01"

  retry_join {
    leader_api_addr         = "https://bao-node-01.internal.net:8200"
    leader_client_cert_file = "/etc/openbao.d/certs/vault.crt"
    leader_client_key_file  = "/etc/openbao.d/certs/vault.key"
    leader_ca_cert_file     = "/etc/openbao.d/certs/ca.crt"
  }

  retry_join {
    leader_api_addr         = "https://bao-node-02.internal.net:8200"
    leader_client_cert_file = "/etc/openbao.d/certs/vault.crt"
    leader_client_key_file  = "/etc/openbao.d/certs/vault.key"
    leader_ca_cert_file     = "/etc/openbao.d/certs/ca.crt"
  }

  retry_join {
    leader_api_addr         = "https://bao-node-03.internal.net:8200"
    leader_client_cert_file = "/etc/openbao.d/certs/vault.crt"
    leader_client_key_file  = "/etc/openbao.d/certs/vault.key"
    leader_ca_cert_file     = "/etc/openbao.d/certs/ca.crt"
  }

  autopilot {
    cleanup_dead_servers      = true
    last_contact_threshold    = "10s"
    max_trailing_logs         = 1000
    server_stabilization_time = "10s"
  }
}

# Automated Unseal via AWS KMS
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/b5d84c20-7f41-419a-9e12-openbao-unseal"
}

# Alternative Transit Auto-Unseal configuration (uncomment for hybrid cloud)
# seal "transit" {
#   address            = "https://transit-vault.corp.internal:8200"
#   token              = "s.auto-unseal-transit-token"
#   disable_renewal    = "false"
#   key_name           = "openbao-cluster-key"
#   mount_path         = "transit/"
#   tls_ca_cert        = "/etc/openbao.d/certs/transit-ca.crt"
# }

listener "tcp" {
  address                  = "0.0.0.0:8200"
  cluster_address          = "0.0.0.0:8201"
  tls_disable              = 0
  tls_cert_file            = "/etc/openbao.d/certs/vault.crt"
  tls_key_file             = "/etc/openbao.d/certs/vault.key"
  tls_client_ca_file       = "/etc/openbao.d/certs/ca.crt"
  tls_min_version          = "tls12"
  tls_cipher_suites        = "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
  x_forwarded_for_authorized_addrs = "10.0.0.0/16"
}

api_addr     = "https://bao-node-01.internal.net:8200"
cluster_addr = "https://bao-node-01.internal.net:8201"

# Performance Tuning Parameters
cluster_name                   = "openbao-enterprise-prod"
default_lease_ttl              = "168h"
max_lease_ttl                  = "720h"
cache_size                     = 131072
disable_cache                  = false
performance_standby_node_count = 1

telemetry {
  prometheus_retention_time = "24h"
  disable_hostname          = true
}

Memory Pinning and Systemd Service Unit

Because OpenBao holds cryptographic keys and decrypted values in process memory, the operating system must never swap these pages to disk. We enforce mlock via Linux capabilities in the systemd service definition:

# /etc/systemd/system/openbao.service
[Unit]
Description="OpenBao Secrets Management Server"
Documentation=https://openbao.org/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/openbao.d/openbao.hcl

[Service]
User=openbao
Group=openbao
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/local/bin/bao server -config=/etc/openbao.d/openbao.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
LimitNOFILE=65536
LimitNPROC=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

---

Step-by-Step Zero-Downtime Migration Blueprint

Migrating an enterprise cluster with active token leases and dynamic secrets requires an ordered, verified procedure. The following blueprint demonstrates a migration from open-source HashiCorp Vault 1.14.x to OpenBao.

Step 1: Pre-Flight Compatibility and Cryptographic Audit

Before initiating the migration, verify your source Vault cluster version and cryptographic barrier state. Direct raw snapshot restoration is officially supported for Vault 1.14.x CE. If running Vault 1.15.0+ or Vault Enterprise with proprietary features such as Namespaces, plan an API-level migration rather than raw snapshot restoration.

# Verify active Vault version (Target: Vault 1.14.x CE)
vault status

# Expected output:
# Key                      Value
# ---                      -----
# Recovery Seal Type       shamir / awskms
# Initialized              true
# Sealed                   false
# Storage Type             raft
# Cluster Name             vault-prod-cluster
# Version                  1.14.8

# Verify Raft cluster peer stability and voter status
vault operator raft list-peers

Falsifiability Check: Ensure no pending uncommitted Raft transactions exist. If raft.applied_index differs significantly across nodes in your Prometheus metrics, pause and resolve storage network lag before proceeding.

Step 2: Atomic Raft Snapshot Export and Integrity Hashing

Export an atomic snapshot of the entire Raft database state directly from the active leader:

# Capture atomic snapshot
vault operator raft snapshot save /var/backups/vault_migration_baseline.snap

# Compute strict SHA256 integrity digest
sha256sum /var/backups/vault_migration_baseline.snap | tee /var/backups/vault_migration_baseline.snap.sha256

# Verify snapshot file structure and header validity
file /var/backups/vault_migration_baseline.snap
# Expected output: /var/backups/vault_migration_baseline.snap: gzip compressed data

Step 3: Target Cluster Staging and Configuration Mapping

Install the official OpenBao binary on your provisioned target nodes:

# Fetch and verify OpenBao release
BAO_VERSION="2.1.0"
curl -sSL -O https://github.com/openbao/openbao/releases/download/v${BAO_VERSION}/bao_${BAO_VERSION}_linux_amd64.tar.gz
curl -sSL -O https://github.com/openbao/openbao/releases/download/v${BAO_VERSION}/bao_${BAO_VERSION}_SHA256SUMS

# Verify binary integrity
grep "bao_${BAO_VERSION}_linux_amd64.tar.gz" bao_${BAO_VERSION}_SHA256SUMS | sha256sum -c -
tar -xzf bao_${BAO_VERSION}_linux_amd64.tar.gz
sudo mv bao /usr/local/bin/
sudo chmod 0755 /usr/local/bin/bao

Convert the configuration file:

• Update binary paths from vault to bao.
• Ensure /etc/openbao.d/openbao.hcl configures the seal "awskms" block pointing to the exact same AWS KMS key ARN used by the source Vault cluster (ensuring IAM policies permit kms:Decrypt, kms:Encrypt, and kms:DescribeKey).
• Start the OpenBao systemd unit on the target leader node.

Step 4: Snapshot Restoration and KMS Auto-Unseal Workflow

To restore a Raft snapshot into OpenBao, the target cluster must be initialized so its API endpoints can accept authenticated administrative commands.

export BAO_ADDR="https://bao-node-01.internal.net:8200"
export BAO_SKIP_VERIFY=true

# 1. Initialize OpenBao leader node with temporary recovery keys
bao operator init -key-shares=1 -key-threshold=1 | tee /root/bao_init.txt

# 2. Extract temporary initial root token
export BAO_TOKEN=$(grep 'Initial Root Token:' /root/bao_init.txt | awk '{print $NF}')

# 3. Force restore the Vault 1.14.x snapshot into OpenBao's Raft state machine
# The -force flag bypasses cluster ID checks and overwrites the local state
bao operator raft snapshot restore -force /var/backups/vault_migration_baseline.snap

# 4. Restart OpenBao service to re-read the restored Raft state from disk
sudo systemctl restart openbao

# 5. Validate auto-unseal status
bao status

During service startup, OpenBao initializes its cryptographic barrier against the restored Raft storage. Because the configured AWS KMS key ARN matches the encryption barrier used when creating the snapshot, OpenBao sends the encrypted root keyring to AWS KMS, receives the decrypted barrier master key, and unseals automatically without manual Shamir reconstruction.

Note: Once restored, administrative authentication requires the root token or unseal credentials from the source Vault cluster, as the snapshot replaces all token tables and policies.

Step 5: Quorum Verification and Traffic Cutover

Join the remaining OpenBao follower nodes to the newly restored cluster:

# On Node 2 and Node 3:
sudo systemctl start openbao
bao operator raft join https://bao-node-01.internal.net:8200

# Verify Raft peers on the OpenBao leader
bao operator raft list-peers

# Expected Output:
# Node                                    Address                             State       Voter
# ----                                    -------                             -----       -----
# bao-node-01 (leader)                   bao-node-01.internal.net:8201      leader      true
# bao-node-02                            bao-node-02.internal.net:8201      follower    true
# bao-node-03                            bao-node-03.internal.net:8201      follower    true

Perform an API functional verification:

# Verify KV-v2 secrets accessibility
bao kv get secret/production/database/credentials

# Verify dynamic secret engines
bao read database/creds/analytics-read

Once validated, shift AWS Route 53 weighted records or update your DNS CNAME from the HashiCorp cluster to the OpenBao cluster incrementally (10% $\rightarrow$ 50% $\rightarrow$ 100%) while monitoring application error rates and latency metrics.

---

Concrete Integration Traces: Dynamic PostgreSQL Secrets and Kubernetes Auth

To demonstrate configuration continuity post-migration, we verify two critical enterprise secret patterns on OpenBao: dynamic PostgreSQL credentials and Kubernetes pod authentication.

PostgreSQL Dynamic Credential Engine Configuration Trace

OpenBao generates just-in-time PostgreSQL credentials with strict Time-To-Live (TTL) expiration, minimizing database blast radiuses:

# 1. Enable Database Secrets Engine on OpenBao
bao secrets enable database

# 2. Configure PostgreSQL Connection Plugin
bao write database/config/postgresql \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="analytics-read" \
    connection_url="postgresql://{{username}}:{{password}}@postgres.internal.net:5432/analytics?sslmode=verify-full&sslrootcert=/etc/openbao.d/certs/db-ca.pem" \
    username="bao_admin" \
    password="SuperSecretAdminPassword123!" \
    max_open_connections=20 \
    max_idle_connections=10 \
    max_connection_lifetime="600s"

# 3. Create Rotational Dynamic Role with 1-Hour TTL
bao write database/roles/analytics-read \
    db_name="postgresql" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

# 4. Generate On-Demand Dynamic Credential
bao read database/creds/analytics-read

Output trace from OpenBao:

{
  "request_id": "7f3e8201-9c44-42ea-a9b1-6a2c3d8e9f01",
  "lease_id": "database/creds/analytics-read/VpQ8n0Kj9x4r2Z1m7b3v8L0p",
  "renewable": true,
  "lease_duration": 3600,
  "data": {
    "password": "A1b!9xYz_TemporarySecretGeneratedByBao",
    "username": "v-token-analyti-VpQ8n0Kj9x4r2Z"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

The database engine creates the temporary role in PostgreSQL, which drops automatically when the OpenBao lease expires.

Kubernetes Authentication and Projected Service Account Tokens

OpenBao verifies projected Kubernetes ServiceAccount tokens (PSAT) via the Kubernetes TokenReview API:

# 1. Enable Kubernetes Auth Method
bao auth enable kubernetes

# 2. Configure Auth Engine with Local Cluster API Credentials
bao write auth/kubernetes/config \
    kubernetes_host="https://kubernetes.default.svc.cluster.local:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    token_reviewer_jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

# 3. Bind Kubernetes ServiceAccount to OpenBao Access Policy
bao write auth/kubernetes/role/payment-service \
    bound_service_account_names="payment-processor" \
    bound_service_account_namespaces="production" \
    policies="payment-service-policy" \
    ttl="1h"

Workloads inside Kubernetes authenticate by mounting projected service account tokens:

# Kubernetes Pod Deployment Manifest Fragment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
  namespace: production
spec:
  replicas: 3
  template:
    spec:
      serviceAccountName: payment-processor
      containers:
      - name: app
        image: internal-registry.corp/payment-service:v2.4.0
        env:
        - name: BAO_ADDR
          value: "https://bao.internal.net:8200"
        volumeMounts:
        - name: vault-token
          mountPath: /var/run/secrets/tokens
      volumes:
      - name: vault-token
        projected:
          sources:
          - serviceAccountToken:
              path: vault-token
              expirationSeconds: 600
              audience: "https://bao.internal.net:8200"

The microservice issues a POST request to /v1/auth/kubernetes/login submitting /var/run/secrets/tokens/vault-token. OpenBao validates the token against the Kubernetes API server and returns a cryptographically scoped client token.

---

Enterprise Licensing TCO Comparison: IBM/HashiCorp Commercial vs. OpenBao

Evaluating a migration to OpenBao involves weighing software licensing expenses, operational independence, and internal platform engineering requirements.

Commercial Tier Cost Breakdown and Hidden Licensing Multipliers

HashiCorp Vault commercial licensing relies on metrics that scale alongside an organization's cloud-native adoption:

1. Billable Secret Clients: Commercial licenses meter "active clients" (any unique entity, token, or service account that interacts with Vault within a monthly billing cycle). In dynamic Kubernetes environments with short-lived pods, ephemeral workloads can increase active client counts unless tokens and entities are carefully reused.

2. Enterprise Feature Entitlements: Advanced capabilities such as Multi-Region Disaster Recovery (DR), Performance Replication, and Enterprise Namespaces are commercial enterprise modules negotiated under custom master services agreements.

3. Audit and Renewal Cycles: Proprietary software agreements require annual renewal negotiations and client-usage reconciliation.

Three-Year Enterprise TCO Model (15-Node Multi-Cluster Deployment)

To evaluate potential budgetary impact, the following model outlines an illustrative enterprise scenario comparing a 15-node production footprint across Development, Staging, and Multi-AZ Production environments (supporting approximately 10,000 active client entities):

Disclaimer & Modeling Assumptions: HashiCorp Vault Enterprise self-managed contracts are custom-quoted based on enterprise negotiation, client count thresholds, and selected modules; figures shown reflect a representative commercial budgeting model based on industry market surveys. HCP Vault Dedicated figures reflect published list rates for Standard/Plus tiers. OpenBao licensing is $0 under the perpetual MPLv2 license; self-managed infrastructure and engineering operational costs remain the responsibility of the adopting organization.

Operational Overhead vs. Vendor Lock-In Trade-Offs

While deploying OpenBao eliminates direct proprietary software licensing fees, engineering leadership must balance these savings against operational responsibilities:

• Infrastructure Management: Self-managed OpenBao requires internal platform engineering competence in Linux system tuning, EBS volume performance, and automated Raft snapshot orchestration.
• Audit and Compliance Independence: Deploying open-source software under MPLv2 removes commercial seat-count auditing obligations and proprietary renewal renegotiations, replacing them with self-managed operational ownership.
• Tooling Continuity: When modernizing identity backplanes and dynamic credentials, organizations frequently collaborate with specialized engineering teams for custom software engineering services to automate secret synchronization, construct Kubernetes operator pipelines, and integrate internal PKI workflows.

---

Frequently Asked Questions

Can OpenBao directly restore snapshots created by HashiCorp Vault Enterprise?

Direct raw Raft snapshot restoration is officially supported when migrating from open-source HashiCorp Vault 1.14.x (up to 1.14.8 CE). Clusters running Vault 1.15.0 or later, or Vault Enterprise instances utilizing proprietary features like Namespaces, cannot be restored via raw Raft snapshots due to post-1.14 storage schema differences and proprietary metadata. For those environments, data must be migrated logically using the HTTP API, export/import scripts, or dedicated migration utilities.

How does OpenBao handle enterprise namespaces found in commercial HashiCorp Vault clusters?

HashiCorp Vault Enterprise isolates tenants using namespaces (e.g., ns1/secret/foo). In OpenBao, tenant isolation is achieved by mapping former namespaces into structured mount path hierarchies (such as /tenants/ns1/secret/foo) governed by granular path-based access control policies, or by utilizing OpenBao's community-driven multi-tenancy constructs via API data export and import pipelines.

Will existing client SDKs and CSI drivers work with OpenBao without modifications?

Yes. OpenBao maintains strict wire-protocol compatibility with the /v1/ HTTP API. Standard libraries—including hashicorp/vault/api in Go, hvac in Python, Spring Cloud Vault, and the official Secrets Store CSI Driver for Kubernetes—communicate with OpenBao endpoints without code alterations or recompilation.

What are the primary performance bottlenecks when scaling OpenBao Raft clusters beyond 10,000 requests per second?

At workloads exceeding 10,000 RPS, the primary constraint is disk fsync(2) write latency on the Raft leader. Because all state mutations require synchronous disk flushes to maintain consensus across voting peers, storage volumes must guarantee low queue depths and consistent IOPS (such as AWS EBS io2 or local NVMe SSDs). Read operations can scale horizontally across performance standby nodes without impacting leader write throughput.

---

Sources

• OpenBao Official Project Repository - The Linux Foundation OpenBao open-source source tree and documentation.
• The Linux Foundation Announces Launch of OpenBao - Official charter, governance model, and open security mandate.
• HashiCorp Business Source License (BSL) FAQ - Official documentation detailing the BSL 1.1 transition.
• HashiCorp Vault Integrated Storage Documentation - Technical mechanics of Raft consensus and state machine replication.
• In Search of an Understandable Consensus Algorithm (USENIX ATC '14) - Original Raft consensus specification by Diego Ongaro and John Ousterhout.