Introduction: The Shift in Enterprise Secrets Management

In the modern cloud-native landscape, managing sensitive data—such as API keys, database credentials, and SSL certificates—has become a cornerstone of robust DevSecOps practices. For years, HashiCorp Vault stood as the industry standard for securing, storing, and tightly controlling access to these tokens. However, recent licensing changes have prompted enterprise architects to re-evaluate their dependency on proprietary ecosystems. Enter OpenBao, an open-source fork of Vault managed under the auspices of the Linux Foundation.

As organizations strive for higher security compliance, the concept of immutability has shifted from infrastructure to configuration and secrets management. Building an immutable secrets management system implies that once secrets and their access policies are defined, they cannot be altered inline; instead, any change requires a structured, version-controlled redeployment. This blog post provides an enterprise-grade blueprint for migrating from Vault to OpenBao within a CI/CD cluster environment while implementing an immutable operational model.

Why OpenBao? The Architectural and Licensing Imperative

When HashiCorp transitioned Vault from the Mozilla Public License (MPL) to the Business Source License (BSL), it introduced strategic risks for organizations building downstream commercial platforms or relying heavily on open-source ecosystem integrations. OpenBao emerged to preserve the original community-driven, fully open-source trajectory of the project.

Architecturally, OpenBao maintains functional compatibility with Vault’s core APIs, making it an ideal drop-in replacement. It inherits the battle-tested storage layout, cryptographic barriers, and plugin system that engineers are familiar with. By switching to OpenBao, enterprises retain full control over their security roadmap without fearing licensing non-compliance, all while benefiting from community-driven peer reviews and rapid vulnerability patching.

The Paradigm of Immutable Secrets Management

Traditional secrets management often treats backend engines as mutable databases where administrators or automated scripts can ad-hoc modify keys, update paths, or alter policies. This introduces configuration drift, compromises auditability, and increases the blast radius of a compromised credential.

An immutable secrets management architecture flips this paradigm by enforcing the following principles:

Declarative Policy Definition: Access control lists (ACLs) and secret engines are defined strictly as code (e.g., via Terraform or OpenBao Provider configurations) stored in a secure Git repository.
Ephemeral Execution Contexts: CI/CD pipelines do not hold long-lived tokens. They dynamically authenticate, consume single-use or short-lived dynamic secrets, and immediately invalidate the session.
Zero Manual Drift: Direct modification of OpenBao configurations via the UI or CLI is explicitly disabled in production. Any configuration adjustment triggers a controlled redeployment or systematic convergence through a GitOps operator.

Immutability eliminates human error from the cryptographic equation. When configurations are static and reproducible, anomalous behavior becomes instantly visible and easier to isolate.

Step-by-Step Migration from Vault to OpenBao in CI/CD

Transitioning a live production CI/CD cluster from Vault to OpenBao requires a meticulous approach to prevent pipeline disruption. Because OpenBao maintains strict compatibility with the underlying Vault storage engines (such as Raft Integrated Storage or Consul), a zero-downtime migration is achievable through the following systematic phases.

Phase 1: Pre-Migration Audit and Backup

Before modifying any cluster components, a comprehensive state capture must be executed. This ensures a reliable rollback path if the migration encounters unexpected state anomalies.

Execute a comprehensive snapshot of the existing Vault storage backend using the native operational utilities.
Export all active system configurations, mount points, enabled auth methods, and non-sensitive policy definitions to an offline verification manifest.
Verify that all active CI/CD runners are using compatible client utilities or standard environment variables (like VAULT_ADDR) that can be seamlessly remapped to OpenBao.

Phase 2: Preparing the OpenBao Cluster

Deploy the OpenBao binaries alongside or in place of the existing Vault instances. If utilizing Kubernetes-based CI/CD clusters (such as ArgoCD or GitLab CI on K8s), update the Helm chart definitions or operator manifests to reference the official OpenBao container images.

Configure the initial environment variables to match your existing topology, ensuring that network listener blocks, TLS configurations, and storage stanzas point accurately to the verified backend data storage layers. OpenBao natively understands the structural storage layout of pre-BSL Vault instances, allowing it to assume data ownership smoothly.

Phase 3: Data Migration and Unsealing

Once the OpenBao pods or nodes are online, bring them up in standby mode against the existing storage backend. If you are using Raft integrated storage, you can systematically join OpenBao nodes to the existing cluster raft group, allow data synchronization to complete, and then gracefully decommission the old Vault nodes.

When initializing the unseal process on the newly provisioned OpenBao nodes, utilize your existing Shamir unseal keys or cloud-native auto-unseal mechanisms (such as AWS KMS, Azure Key Vault, or GCP KMS). The underlying cryptographic barrier will successfully decrypt, exposing the existing secrets pathways without modifications.

Phase 4: Traffic Routing and Pipeline Validation

Update internal cluster ingress routing, CoreDNS aliases, or service meshes to redirect traffic from the old endpoint to the new OpenBao service endpoint. Because OpenBao responds to the standard Vault API paths (e.g., /v1/auth/..., /v1/secret/...), existing CI/CD plugins, Jenkins credential wrappers, and GitHub Actions runners will function natively without requiring direct modification of their codebases.

Integrating OpenBao into an Immutable GitOps CI/CD Pipeline

With OpenBao active, the final step is locking down the architecture to enforce total immutability within the CI/CD workflow. This is achieved by combining GitOps patterns with dynamic secret engines.

1. GitOps-Driven Configuration

Use tools like ArgoCD or Flux to deploy OpenBao configurations. Define all namespaces, engines, and policies in a Git repository. Any changes to access levels must undergo a pull request review, passing automated validation checks before being applied to the cluster. If manual tampering occurs on the live OpenBao cluster, the GitOps operator will automatically reconcile the state back to the approved Git commit definition.

2. Leveraging AppRole and OIDC for Runner Authentication

Eliminate long-lived root tokens from pipelines entirely. Utilize short-lived AppRole authentication or native OIDC/JWT authentication tied directly to the CI/CD runner's identity providers (such as GitLab CI JWT or GitHub Actions OIDC tokens). When a pipeline job initiates, it presents its ephemeral identity token to OpenBao, receives a scoped token valid exclusively for the duration of that specific job execution, and then automatically expires.

3. Utilizing Dynamic Secrets Engines

To achieve true immutability, move away from static key-value storage. Enable OpenBao dynamic secrets engines for databases, cloud providers, and container registries. Instead of reading a static database password, the CI/CD pipeline requests temporary credentials from OpenBao. OpenBao dynamically creates a unique user account on the target system with a strict Time-To-Live (TTL) of mere minutes and automatically drops the database user once the pipeline completes. This ensures that even if a build log is accidentally exposed, the leaked credential is already completely invalid.

Conclusion: Embracing Future-Proof Security

Migrating from HashiCorp Vault to OpenBao offers more than just a remedy for licensing uncertainties—it presents a timely opportunity to modernize your cloud security baseline. By moving to a truly open-source platform managed under neutral governance, enterprise operations teams ensure long-term stability and ecosystem continuity.

When combined with an immutable architectural approach—enforced through GitOps engines, declarative policy management, and dynamic short-lived credentials—your CI/CD cluster transforms into a hardened environment. Security shifts from an operational bottleneck into an automated, invisible, and highly resilient component of your delivery pipeline.

Building an Immutable Secrets Management System: Transitioning from Vault to OpenBao in CI/CD Clusters