Introduction to Modern Secret Management in CI/CD

In the contemporary DevOps landscape, continuous integration and continuous delivery (CI/CD) pipelines serve as the engine of software deployment. However, this engine requires significant privileges, often demanding access to cloud infrastructure, databases, third-party APIs, and registry credentials. Historically, organizations managed these sensitive assets—collectively known as secrets—by hardcoding them into configuration files or storing them as static environment variables within CI/CD platforms.

This static approach introduces profound security risks. Hardcoded credentials are vulnerable to repository leaks, while static secrets stored in continuous integration tools present an attractive target for lateral movement during a security breach. To mitigate these vectors, modern infrastructure demands a dynamic, centralized secret management solution. This blog post explores how to deploy OpenBao, an open-source, community-driven fork of HashiCorp Vault, to manage and automatically rotate API keys and secrets across a distributed cluster of Virtual Private Servers (VPS) dedicated to CI/CD workloads.

What is OpenBao and Why Fork from HashiCorp Vault?

For years, HashiCorp Vault stood as the industry standard for secret management, offering robust encryption, dynamic secret generation, and detailed audit logging. However, HashiCorp's transition of its core product suite from the open-source Mozilla Public License (MPL) to the proprietary Business Source License (BSL) created compliance and operational challenges for many enterprises and open-source advocates.

In response to this licensing shift, the Linux Foundation housed OpenBao. OpenBao preserves the robust, highly scalable, and secure architecture of the original open-source Vault code while ensuring it remains a community-governed, genuinely open-source project. For enterprises operating cost-effective, distributed VPS networks for their CI/CD engines, OpenBao offers a production-grade, compliance-friendly platform without vendor lock-in or licensing overhead.

Architectural Overview: OpenBao on a Distributed VPS Cluster

When deploying OpenBao to manage secrets across a fleet of CI/CD runner VPS instances, the architectural design must prioritize both high availability and strict segregation of duties. Relying on a single OpenBao node introduces a single point of failure (SPOF) that can halt your entire deployment pipeline.

The Architecture Components

OpenBao Cluster (Control Plane): A minimum of three dedicated VPS instances configured in a high-availability (HA) cluster utilizing a consensus algorithm backend (such as Raft Integrated Storage) to synchronize state and handle failovers transparently.
CI/CD Runner Fleet (Data Plane): Distributed VPS instances executing pipeline jobs (e.g., GitLab Runners, GitHub Actions self-hosted runners, or Jenkins agents). These instances do not store long-lived secrets; instead, they query the Control Plane dynamically.
Reverse Proxy / Load Balancer: A highly available load balancer (such as HAProxy or Nginx) that distributes incoming API traffic across the active and standby OpenBao nodes.

Security Note: All traffic between the CI/CD runners, the load balancer, and the OpenBao cluster must be strictly encrypted transitively using Transport Layer Security (TLS 1.3). Never allow unencrypted HTTP traffic within your secret management infrastructure.

Step-by-Step Guide to Deploying OpenBao

Step 1: Preparing the VPS Environment

Begin by provisioning three Linux-based VPS instances for your OpenBao cluster. Ensure that network firewalls (security groups) restrict access to the OpenBao ports. By default, OpenBao listens on port 8200 for client API requests and port 8201 for internal cluster server-to-server traffic.

Step 2: Installing OpenBao

Because OpenBao maintains compatibility with the original Vault CLI and configuration syntax, installation remains streamlined. Fetch the official binaries verified by the Linux Foundation repository or compile from source. Once placed in the system execution path, create a dedicated system user and directory structure to enforce the principle of least privilege:

sudo useradd --system --home /etc/openbao --shell /bin/false openbao
sudo mkdir --parents /opt/openbao/data /etc/openbao
sudo chown --recursive openbao:openbao /opt/openbao /etc/openbao

Step 3: Configuring Raft Storage for High Availability

Create the primary configuration file at /etc/openbao/bao.hcl. Below is a production-ready configuration snippet demonstrating how to configure Raft integrated storage and TLS bindings:

storage "raft" {
  path    = "/opt/openbao/data"
  node_id = "bao-node-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/openbao/certs/bao.crt"
  tls_key_file  = "/etc/openbao/certs/bao.key"
}

cluster_address = "10.0.0.11:8201"
api_addr        = "[https://bao.internal.domain:8200](https://bao.internal.domain:8200)"
ui              = true

Repeat this configuration across all cluster nodes, updating the node_id, cluster_address, and storage paths accordingly. Start the systemd service to initialize the cluster.

Implementing Automated Secret Rotation for CI/CD

Centralizing secrets solves the storage problem, but human error and credential degradation over time remain threats. The true power of OpenBao lies in its Dynamic Secrets Engine, which generates credentials on-the-fly and automatically destroys them when their Time-To-Live (TTL) expires.

How Automated Secret Rotation Functions

Unlike static keys that persist until manually changed, automated rotation ensures that if a secret is leaked during a CI/CD build execution, that secret becomes invalid shortly thereafter. Let's look at how to implement this for database credentials and cloud provider API keys.

Enable the Target Secret Engine: Instruct OpenBao to manage a specific target system, such as an AWS cloud environment or a PostgreSQL cluster used for staging deployments.
Define a Role and TTL: Configure a role that dictates the precise permissions the temporary secret will possess, alongside a strict max TTL (e.g., 30 minutes).
Dynamic Generation: When a CI/CD pipeline starts on a VPS runner, it uses its machine identity to authenticate with OpenBao and requests credentials for that specific role. OpenBao interfaces with the target provider, generates a unique API key or database user, and hands it to the runner.
Automated Revocation: Once the pipeline completes or the TTL expires, OpenBao automatically contacts the target provider to delete or revoke the credential, requiring zero intervention from system administrators.

Configuring a AppRole Authentication for VPS Runners

To safely allow a CI/CD runner running on an isolated VPS to fetch secrets without utilizing a master password, leverage the AppRole Authentication Method. AppRole is designed specifically for machine-to-machine communication:

First, enable AppRole authentication via the OpenBao CLI:

bao auth enable approle

Next, define a policy that restricts access only to the specific secrets required by the deployment pipeline, and bind this policy to a runner role:

bao write auth/approle/role/cicd-runner \
    secret_id_ttl="10m" \
    token_num_uses=10 \
    token_ttl="20m" \
    token_max_ttl="30m" \
    policies="cicd-deploy-policy"

The CI/CD platform securely passes a RoleID and a short-lived SecretID to the target VPS runner at runtime. The runner presents these components to OpenBao to receive an ephemeral client token, dramatically narrowing the window of vulnerability.

Best Practices for Securing the OpenBao Control Plane

Deploying OpenBao successfully requires strict adherence to institutional security hardening strategies. Consider the following foundational rules:

Production Unsealing: Never use a single unseal key in production. Utilize Shamir's Secret Sharing to split the unseal key among multiple trusted engineers, or leverage cloud-native KMS auto-unsealing to prevent human intervention during node restarts.
Audit Logging: Enable detailed audit backends immediately. Every API interaction with OpenBao—whether a successful read or a denied attempt—must be securely streamed to an isolated, immutable log management system.
Memory Locking: Ensure that disable_mlock is set to false in your configuration file. This prevents the operating system from swapping OpenBao memory pages onto physical disk space, keeping sensitive plaintext cryptographic data strictly within RAM.

Conclusion

Migrating from static, fragmented environment variables to a community-backed, centralized paradigm using OpenBao represents a major milestone in hardening your infrastructure. By establishing a high-availability OpenBao cluster across your VPS network and implementing automated secret rotation via AppRole, you effectively eliminate the threat of long-lived credential exposure. As compliance demands tighten and supply chain vulnerabilities multiply, investing in robust open-source secret governance ensures your pipelines remain both agile and uncompromised.

Securing CI/CD Pipelines: Deploying OpenBao for Automated API Key and Secret Rotation Across VPS Clusters