OpenBao Blog | OpenBao

We are thrilled to announce the availability of OpenBao v2.7, adding PostgreSQL horizontal scalability, External HSM and KMS-Backed Keys support, and Post-Quantum Cryptography!
Despite a shorter turnaround than from v2.5.x to v2.6.x, we were excited to see many substantial features and several major security patches land within this release. Many thanks to all the contributors and security reporters!
We are thrilled to announce the availability of OpenBao v2.6, adding per-namespace sealing and the new workflow engine for cross-plugin communication!
Our most collaborative release to date, v2.6 features contributions from 42 first-time contributors, 27 individuals contributing multiple changes, and 8 users with double-digit change counts. Simply fantastic work and a big thanks to the community that makes this happen!
OpenBao v2.6.x has been out for a month now and v2.7.x will soon follow, stay tuned for more releases!
GitOps helps us declare our desired workloads, but how do we deal with and manage secrets? Additionally, as our fleet grows, we also blend artifacts and configuration from many different sources. How do we trust what we are running?
OpenBao is an open source secrets and encryption platform under the OpenSSF. In this post we'll integrate OpenBao with Flux in two ways:
For both integrations, we'll use two OpenBao features. The Transit secrets engine performs encrypt, decrypt, and sign operations without ever releasing the key material, acting as a Key Management System (KMS), and the Kubernetes and JWT auth methods let a workload trade its Kubernetes-issued ServiceAccount token for a short-lived OpenBao token, so no long-lived credential has to exist on either the OpenBao or Kubernetes side.
This is the fifth part of a multi-part series on OpenBao's features.
Last time we talked about declarative plugin configuration and how it made deploying and adopting plugins much easier. With OCI-based distribution operators can deploy plugins with just a few configuration snippets, mirroring OpenTofu's approach.
We hinted at addressing two of the most-requested features in HashiCorp Vault: recursive list support and filtering of list responses.
As mentioned there by Vault community members, we've supported recursive lists since OpenBao v2.2.0 and filtered lists since OpenBao v2.4.0. And, for any plugin developers out there, we support it in our external plugin SDK including storage helpers which should work on Vault as well.
What other places need recursive list support?
Reach out to us if we've missed one!
This is the fourth part of a multi-part series on OpenBao's features.
Last time we talked about how to declaratively configure audit devices and initialize OpenBao. We saw how this made integration of OpenBao in a wider ecosystem or product (such as EdgeX) easier.
Like the last part, this part focuses on the operator experience, but for consumption of OpenBao's plugins: auth methods, secrets engines, auto-unseal devices, and more.
Our motivation here is to build towards a more OpenTofu-like, extensible ecosystem. Easier consumption, community-maintained plugins, and a future plugin registry will lead to more developers writing plugins and expand the usefulness of OpenBao for everyone.
What integrations would you like OpenBao to have? How would you like to see writing plugins made easier?
Contact us to share your thoughts or contribute to the ecosystem!
Slides and content from Michael's talk at Open Source @ Siemens 2026, diving into OpenBao's origins and why it is the sustainable choice.
For a video, see Siemens' official YouTube channel.
SVG rendering is not supported on your browser.
Welcome everyone to my talk on OpenBao and sustainable secrets management! I'm Michael "Hofi" Hofer, CTO at Adfinis and Chair of the OpenBao Technical Steering Committee (TSC).
It's fantastic to be back here in Zug for Open Source @ Siemens - for me personally, this event is always an annual highlight. Huge thanks to the Siemens crew for organizing such a great event! Every year it gets better, and this time we even have romantic ambient lighting to go with it. I'm already looking forward to next year.
Also, a quick shout-out to Jan and Pasquale for the overview on CIP earlier. It's really cool to see a neighboring Linux Foundation project in action.
Today I want to share how we can ensure secrets management remains open, community-driven, and sustainable for decades to come.
This is the third part of a multi-part series on OpenBao's features.
In the past few parts, we talked about low-level technical features that OpenBao core maintainers and plugin authors can take advantage of to make secrets management safer and more scalable.
This part focuses on something that applies to operators of OpenBao: better operator experience for initial configuration. We focus on one question:
How can we make initial OpenBao deployment easier and more reproducible?
This is second part of a multi-part series on OpenBao's features.
Today we focus on transactional storage. While the earlier blog posts focused on the what and how of transactions in Raft, this post will focus on the measurable impact of transactions in OpenBao and their lack in Vault. We will demo some possible ways of creating snapshots which cannot restore and are not consistent on Vault and show how we used transactions to achieve consistency on OpenBao.
At Open Source Summit North America, I met Dr. Justin Cappos, professor at NYU and major OpenSSF contributor and working group lead, and several of his students.
Along with broader discussions of how OpenBao and gittuf might integrate, we talked about Shamir's unsealing and its fundamental problem: it is a side-effecting process with high-entropy results. You can wrap it around a common dictionary, hex or base64 encoding, or other means to make the key shares more consumable by humans, but the results will still be complex and hard to input and store.
The problems I'm looking for a scheme to solve are two