As software development matures within an organization, application architectures inevitably expands and development teams need platform engineering support, which in turn requires a stable cryptographic base to deploy the product onto. ControlPlane Enterprise for OpenBao provides a strong, open source root-of-trust for an organization’s platform and, in turn, product engineering team to build on top of and extend.

Unlike Terraform, HashiCorp Vault wasn’t designed for easy extension or redeployment within a larger platform architecture, which can make embedding Vault into an organization’s customer-facing platform rather difficult. Setup is side-effect heavy, forcing an operator to get both a root token for use during initialization and also recovery keys, which are necessary to store long-term. Adding and adopting external plugins requires API-level access to Vault, which means it must be a post-setup step.

Our recent posts on the OpenBao blog share two of the many improvements we’ve made in this area: declarative configuration for self-initialization with delayed recovery key generation and declarative management of plugins.

Declarative OpenBao configuration

The above blogs outline three new areas of declarative configuration for OpenBao:

1. Immediate audit device configuration, including auditing initialization itself, which automatically ensures audit compliance from the first startup. This can be enabled on OpenBao with a configuration snippet like:

   audit "file" "to-stdout" {
       description = "Write audit information to standard output."
       options {
           file_path = "stdout"
       }
   }
   

2. Self-initialization, using a request-in-configuration architecture, which enables OpenBao to start with a pre-existing integration, allowing GitOps pipelines to run immediately without blocking on manual initialization steps. This can be used with a configuration snippet like:

   initialize "authentication" {
       request "mount-userpass" {
           path      = "sys/auth/userpass"
           operation = "create"
           data = {
               type        = "userpass"
               description = "Administrative access to OpenBao."
           }
       }
   
       ...
   }
   

3. Plugin definitions and registration right in the configuration file, which helps to automate plugin adoption and upgrades. This looks like:

   plugin_directory = "/openbao/plugins"
   plugin_auto_download = true
   plugin_auto_register = true
   
   plugin "secret" "aws" {
       image = "ghcr.io/openbao/openbao-plugin-secrets-aws"
       version = "v0.3.1"
       sha256sum = "641ae1858c0f660b4c3761286d627e1dcfd33dc35e7c83eb81ca9050b5bdc6d8"
   }
   

Of these, self-initialization is the most powerful. Exactly once, at startup, you can simulate any API requests you want using a powerful templating and conditional execution engine that integrates with files and environment variables. This gives you full control over the initial contents of OpenBao, including provisioning initial auth methods, policies, secrets engines, and more. Recovery keys are not generated; they’re deferred until a privileged operator manually calls the recovery key rotation endpoint, meaning setup is entirely side-effect free.

Since the initial configuration is immutable and can be safely removed after successful startup, platform operators need a day one configuration management tool, such as OpenTofu, Ansible, or a similar project. It is suggested to use self-initialization to bootstrap the minimum required state, allowing these tools to execute and own the remainder of the configuration.

Usually, this minimum setup involves chaining OpenBao’s authentication to a trusted IDP and setting up a privileged policy to execute against. These enable platform teams to immediately own their GitOps and regulatory compliance at any scale.

Check out the blogs and related documentation for more information.

Pattern for adoption

These tools create a natural pattern through which product and platform engineering teams can incrementally include OpenBao into their estate. By automating the bootstrapping of a baseline state, declarative self-initialization significantly lowers the barrier to entry. Rather than committing to a complete architectural overhaul from day one, platform engineering teams can start small with a targeted use case and progressively expand their OpenBao integration as their platform requirements and operational maturity grow.

A high-level roadmap might look like the following:

1. Proof of concept inclusion of OpenBao within a small portion of your application. Maybe use it to provide cryptography for a feature, store secrets, or serve as an IDP broker.
2. Select or design centralised day-1 management of OpenBao. Consider what manages access controls, what enables authentication methods, and whether you automate with code or with infrastructure-as-code like OpenTofu?
3. Expand adoption to provide dynamic secrets or mTLS client identity for more portions of the internal architecture.
4. Allow clients to bring their own keys for auto-unseal and more. By backing your product’s multi-tenancy with sealed namespaces means that you can have cryptographic ownership over all sensitive data.

GitLab is an example of a complex application which adopts OpenBao to provide its Secrets Manager functionality. GitLab initially started by using OpenBao’s KVv2, which provides static, versioned secrets that are accessible to pipeline runners. GitLab used its existing OIDC integration as an identity provider, with OpenBao storing policies and tenant separation through namespaces, and GitLab Rails as the managing entity.

This pattern is also visible in NVIDIA Cloud Functions, its reference architecture for a global inference service, and OpenBao is used as the platform’s secrets manager with custom plugins.

Built for everyone

This adoption pattern and the features we built to support it aren’t limited to platform teams building large, customer-accessible applications; internal teams providing a single service to many different internal applications can adopt portions of them as well. Declarative configuration for self-initialization and configuration-driven plugin registration makes it easier to spin up dedicated, scoped OpenBao clusters with less maintenance overhead.

Expertise to drive changes

Our goal is to continue building OpenBao as a scalable, stable architecture that product teams can integrate, whether for multi-tenant adoption, managed redeployment for single-tenant SaaS, or on-premises self-hosted applications. This has been driven by our team’s experience building GitLab Secrets Manager and supporting Vault Enterprise at various financial service customers.

In the current OpenBao v2.7.x release series, we led continued development of PostgreSQL horizontal scalability support to make OpenBao easier for customers to operate without needing specialised Raft expertise.

We’ve supported the development and design of efforts such as allowing operators to bring-your-own HSM and KMS-backed keys, especially in the critical PKI and Transit engines.

And for ControlPlane Enterprise for OpenBao, we’ve built FIPS 140-3 compliant images for OpenBao, allowing organizations to ship OpenBao to even their most highly regulated customers.

If you are ready to partner with ControlPlane or learn more about building on top of ControlPlane Enterprise for OpenBao and how we can secure your platform’s adoption through threat modelling, contact our team today to discuss how we can support you and your organization.