Product1 publisher2 min readPublished
A CNCF walkthrough runs OpenBao on a three-instance Postgres cluster with certificate-only logins
The Linux Foundation's fork of Vault can keep its encrypted key-value store inside a CloudNativePG cluster where pg_hba forces both database roles to present a TLS client certificate. The published recipe runs on a six-node Kind playground.
The Product Desk · Product desk
What happened
- A CNCF blog post documents running OpenBao, the Linux Foundation's open-source fork of HashiCorp Vault, with its native postgresql storage backend pointed at a three-instance CloudNativePG cluster.
- Both database roles in the recipe present a TLS client certificate issued through CloudNativePG's DatabaseRole CRD, and explicit pg_hba rules require that certificate on every connection.
- The Postgres cluster is configured for quorum-based synchronous replication, with method any, number 1 and the default dataDurability of required, for zero-data-loss failover.
- The local setup step installs only CloudNativePG, cert-manager, the Barman Cloud plugin and a ClusterImageCatalog, skipping the playground's demo databases.
- Of the two CNCF projects underneath, Kubernetes graduated long ago while CloudNativePG is a Sandbox project under evaluation for Incubation by the Technical Oversight Committee.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- capability There is no database password for the secrets store to rotate or leak; the credential that protects the store is a certificate the cluster issues to each role.
- constraint Anyone lifting these manifests into a real cluster has to size general-purpose workers first, because dedicating nodes to Postgres is what squeezes OpenBao's own placement once anti-affinity is required.
- exposure Availability of the secrets store becomes a database operations problem for the team that deploys it, and the pager covers both a failed Postgres failover and an expired client certificate.
- decision Teams that describe Vault as unavoidable now have to argue the operating cost instead, since the alternative path is written down step by step.
The first thing to work out is where OpenBao itself gets to run. The local environment in the CNCF walkthrough, cnpg-playground, is one Kind cluster of six nodes: a control plane, one labelled for infrastructure workloads, one for application workloads, and three carrying a `node-role.kubernetes.io/postgres` taint [10]. Take out the control plane and the three tainted nodes and two are left [19]. The post flags those two as the constraint on OpenBao once pod anti-affinity arrives in Step 3 [11].
OpenBao's `postgresql` backend turns any Postgres cluster into its encrypted key-value store [2], with `ha_enabled = "true"` for the HA lock table [7], so the survival of every secret depends on the replication settings of the three-instance CNPG cluster [3].
`role-openbao` is the schema owner, used once to run DDL; `role-openbao-rw` is the restricted role OpenBao connects as at runtime [16]. Both get a client certificate, and the post explains why in one line: "a one-shot DDL job is no more entitled to a password lying around than the application is" [18].
`pg_hba.conf` is where that distinction is enforced, the file that decides per connection whether a role needs a certificate, a password, or nothing at all [5]. Because the requirement is written as explicit rules there, an operator who later attaches a password to one of those roles does not thereby get a password-authenticated path back in [4].
The stack is open source end to end, built on Kubernetes and CloudNativePG [21], and there is no cloud database underneath the Postgres [20]. The recipe is not tied to a distribution either: any conformant cluster with enough worker capacity will do [17]. The `Cluster` points `imageCatalogRef` at the `postgresql-minimal-trixie` catalog, and CNPG resolves that to the latest minimal PostgreSQL 18 image, so re-applying the same manifest keeps picking up new patch releases with no `Cluster` edit [15]. That is convenient for patching. It also means the image can change under you when the catalog updates.
Two things decide whether this is a real option for a given team: whether it already runs a three-instance Postgres cluster with quorum-based synchronous replication and has watched a failover happen [8], and whether certificate rotation is in a runbook someone has executed, since cert-manager is installed as part of the same setup [14]. Meet both and a team that describes itself as locked into Vault is making a cost decision [1]. Meet one, and the price of open source here is two new on-call surfaces, Postgres failover and certificate expiry.
What to watch
- Whether the CNCF Technical Oversight Committee moves CloudNativePG from Sandbox to Incubation.
- Whether a follow-up covers migrating an existing OpenBao or Vault dataset into the postgresql backend, or reports a real failover.
- Whether ClusterImageCatalog auto-resolution to new PostgreSQL 18 patch images causes unplanned rolling restarts for teams that copy the manifest.