Skip to main content
📬 Get weekly Production AI insights Practical notes on Kubernetes, AI infrastructure and platform engineering. No spam. Subscribe free
OpenBao 2.7: Post-Quantum TLS, HSM Keys and Postgres Scale
DevOps

OpenBao 2.7: Post-Quantum TLS, HSM Keys and Postgres Scale

What's new in OpenBao 2.7, from the OpenBao team in Prague: external keys for HSMs, post-quantum TLS, read scaling on PostgreSQL, and secrets for AI agents.

LB
Luca Berton
· 4 min read

At Open Source Summit Europe 2026 in Prague, the OpenBao community had just shipped OpenBao 2.7, and I recorded two short Udienza conversations about it: one with Alex Scheel on Thursday, and one with a member of the OpenBao crew by the OpenSSF booth on Wednesday evening.

Luca Berton with Alex Scheel and Toni Tauro at the OpenSSF area in Prague With Alex Scheel and Toni Tauro in Prague.

Alex and I had already met at PlatformCon in London (see secrets management for AI agents with Alex Scheel), so I asked what had changed since. Quotes are from our recordings, lightly edited for clarity, and the technical details are checked against the OpenBao 2.7.0 release notes.

1. External keys: your keys stay in your HSM

“We shipped external key support. You can now run your PKI root backed by an HSM and have key material similar to Vault Enterprise’s managed keys.”

According to the release notes, External Keys let the PKI and Transit secrets engines use KMS plugins to perform cryptographic operations without storing the key material in OpenBao. You map HSM- or KMS-backed keys through the /sys/external-keys APIs and grant access to selected mounts. PKCS#11-backed keys are supported through the kms-pkcs11 plugin in the openbao-plugins repository.

On Wednesday, the OpenBao team put the same news in one sentence: OpenBao now has external keys, “something that HashiCorp Vault has been having for a long time”. For anyone migrating from Vault Enterprise, managed keys were one of the features that blocked the move. In 2.7 they are in the open source project.

2. Post-quantum cryptography

“And, not to bury the lede, we also shipped post-quantum support. As governments start to transition crypto algorithms around 2030, which is coming up sooner than I care to admit sometimes, people need signature algorithms and key exchange mechanisms that are resistant for the next 30, 40, 50 years.”

From the release notes: operators can set tls_key_exchange_preferences on server, agent and proxy listeners to enforce post-quantum key exchange, with hybrid and pure ML-KEM options (X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 and MLKEM1024), and can use ML-DSA certificates on those listeners.

Why this matters now and not in 2030: “harvest now, decrypt later”. Traffic recorded today can be decrypted once quantum computers are good enough. Secrets managers sit on exactly the traffic you would least like decrypted later.

3. Horizontal (read) scalability on PostgreSQL

“In this release we shipped horizontal scalability on top of Postgres.”

The release notes describe it as read scalability on the PostgreSQL storage backend, similar to what already existed for Raft. It requires ha_enabled = true and a cluster_addr reachable from standby nodes to the primary. If leadership is lost for an extended time, standbys come up read-enabled. Many organisations already operate PostgreSQL well, so being able to scale OpenBao on it, rather than learning Raft operations, lowers the barrier.

What’s next on the roadmap

Alex described two big items:

“We’re looking at additional authorisation mechanisms, either as an external plugin or built into OpenBao itself, as a replacement for Sentinel support. And we’re looking at expanding from read scalability to write scalability, which will require a lot of changes to the core architecture.”

A Sentinel replacement would close another gap for Vault Enterprise users, whose Sentinel policies today must be rewritten as ACL policies or moved to an external engine like OPA.

Secrets for AI agents, without exposing them to the model

On Wednesday I asked whether my AI agent can connect to OpenBao. The answer described a pattern I recommend to every team building agents:

“You can securely store your secrets in OpenBao and inject them through a proxy in an authorisation pattern, and send requests from your AI agents to different services without exposing your secrets to the AI.”

In other words, the agent never sees the credential. A proxy adds it to the outbound request after checking policy. That matters most when the model is hosted by a third party, as the OpenBao team pointed out, and it fits the identity, policy, limits and audit model from the AWS keynote on trusted agentic workloads.

How to get involved

Alex’s advice: check out the OpenBao project on GitHub, join the community chat, and “just tell us that you’re using it, we’ll be happy to know”. The project site is openbao.org.

Upgrade checklist for 2.7

  1. Read the release notes for your storage backend. The PostgreSQL HA settings are new.
  2. Pilot external keys with a non-production PKI mount before moving root CAs to an HSM.
  3. Enable post-quantum key exchange on listeners where all clients support it, and test older clients first.
  4. Move agent credentials behind a proxy so models never receive raw secrets.

More from Prague

Free 30-min Production AI consultation

Book Now