Introduction

Strategic independence begins with the tools you choose to build upon. At Digitalis, we have always championed vendor-neutrality to ensure our customers retain full control of their data and their destiny. In today’s landscape, the risks of proprietary lock-in are no longer theoretical, they are a threat to operational stability. Here, we look at OpenBao, a community-led solution designed to safeguard your secrets while protecting your digital sovereignty.

OpenBao started as a fork of HashiCorp Vault when the licence change prompted the community to create a fully open-source, vendor-neutral secrets management and encryption platform. Since then, it has started to evolve with new features.

In February 2024, the community proposed a plugin solution that would, amongst other things, remove the burden of maintaining a long list of features but a small community. This became a major difference with its parent project HashiCorp Vault that’s worth exploring.

What the heck is a plugin?

When we talk about software extensibility at Digitalis, we often find ourselves discussing the "core vs edge" trade-off. Every platform aims to be a Swiss Army knife, but as many of our clients discover when scaling Kubernetes or complex data pipelines, a tool that tries to do everything natively often becomes bloated, difficult to maintain, and slow to evolve.

This is where the concept of a plugin architecture becomes indispensable. At its simplest, a plugin is a modular software component that adds specific capabilities to an existing application without requiring changes to the host’s core source code. By decoupling the primary logic from optional features, developers can extend a system’s functionality while keeping the core system lean and stable.

Plugins in OpenBao

OpenBao, the community-driven, open-source fork of HashiCorp Vault, inherits and expands upon a sophisticated plugin ecosystem. Since OpenBao is designed to manage, store, and distribute sensitive data across diverse environments, it must be exceptionally flexible. To achieve this, almost everything in OpenBao that isn't the core "barrier" (the part that handles encryption and policy enforcement) is implemented as a plugin.

These plugins generally fall into three primary categories, each serving a distinct role in the secrets management lifecycle:

• Auth Methods: These plugins define how a user or machine proves their identity. Whether you are authenticating via GitHub, LDAP, or Kubernetes Service Accounts, OpenBao uses a plugin to validate those credentials and map them to internal policies.
• Secret Engines: These are responsible for managing the actual sensitive data. While some engines provide static Key/Value storage, others generate "dynamic secrets"—short-lived credentials for AWS, Azure, or Google Cloud. When an application requests access, the secret engine plugin talks to the cloud provider, creates a temporary user, and returns the credentials to the requester.
• Database Plugins: A subset of secret engines, these specifically handle the lifecycle of database credentials. They manage the creation of users and the rotation of passwords across various engines like PostgreSQL, MySQL, or Cassandra.

One of the great things about a plugin model is that you can collaborate with your own developments to the community much easier without affecting the core OpenBao code. This flexibility allows for a rapid innovation cycle where niche requirements can be developed, tested, and shared as standalone binaries.

How do you enable plugins?

Enabling a plugin is not difficult but it can be a bit tedious when you have many to download and enable. You would need to follow these steps:

1. Ensure you have a plugins directory set up on each of the cluster nodes

1plugin_directory = "/opt/openbao/plugins"

      2. Download the pluginto each of the nodes into the directory

      3. Get the sha256 of the binary: you would usually get this from the source, ie, from GitHub or alike. For a local development, you’ll need to calculate it yourself

‍

1$ sha256sum /path/to/myplugin-database-plugin

4. Finally, enable it

1$ bao plugin register -sha256=<SHA256 Hex value of the plugin binary> \
2    secret \                  # type
3    myplugin-database-plugin
4
5Success! Registered plugin: myplugin-database-plugin

‍

     5. Confirm the plugin is now loaded
‍

1$ bao plugin list secret

‍

This system of enabling plugins is not, in my opinion, the best. If you have many plugins and several OpenBao nodes, it’s a lot of work. That’s why the new OCI model on OpenBao 2.5.x is a great addition!

Please note at the time of writing, OpenBao 2.5.x is still in beta

OCI Plugins

The Open Container Initiative (OCI) is an industry-standard governance structure that defines how container images should be formatted (Image-spec) and distributed (Distribution-spec). While we most commonly associate OCI with Docker or Kubernetes, it is essentially a universal standard for packaging any binary and its metadata into an immutable, versioned, and signed artifact.

Instead of downloading the plugins using automation like Ansible (or God forbid, manually!) you can now delegate it to OpenBao itself. All you need is to add them to the config

1plugin_directory = "/opt/openbao/plugins"
2plugin_download_behavior = "fail"
3# The default is false
4plugin_auto_download = true
5
6plugin "secret" "aws" {
7  image       = "ghcr.io/openbao/openbao-plugin-secrets-aws"
8  version     = "v1.0.0"
9  binary_name = "openbao-plugin-secrets-aws"
10  sha256sum   = "9fdd8be7947e4a4caf7cce4f0e02695081b6c85178aa912df5d37be97363144c"
11}

‍

if you prefer to control when the plugins are downloaded, set plugin_auto_download to false and run the command bao plugin init when you’re ready.

Closing Thoughts

In an era where data residency and jurisdictional control are paramount, the ability to decouple your secrets management from a single cloud provider’s roadmap is a strategic necessity. By leveraging a community-driven, open-source framework, organisations can ensure that their security posture isn't dictated by opaque licensing changes or proprietary lock-in. Whether you are running on-premises, in a sovereign European cloud, or across a complex multi-cloud mesh, OpenBao plugins provide the "connective tissue" that keeps your sensitive data under your own cryptographic ownership.

At Digitalis, we believe that true digital autonomy is built on three things: transparency, portability, and extensibility. OpenBao’s plugin model ticks all three boxes, allowing you to:

• Customise without compromise: Extend your security stack to legacy or niche systems without forking the core codebase.
• Modernise your supply chain: Use OCI-based distribution to treat security tooling with the same rigour as your application code.
• Future-proof your infrastructure: Maintain the freedom to switch backends or cloud providers while keeping your central secrets API consistent.

I for one welcome our new robot overlords

‍