FLUX·AI 社区

以下正文同步自 CNCF Blog，版权归原站所有，已转换为易读排版。

Managing infrastructure secrets on Kubernetes needs a backend that is self-healing and free of vendor lock-in, and that is exactly what OpenBao (the Linux Foundation’s open-source fork of HashiCorp Vault) and CloudNativePG give you: an entirely open-source stack built on two CNCF projects, Kubernetes, long since graduated, and CloudNativePG, a CNCF Sandbox project currently under evaluation for Incubation by the CNCF Technical Oversight Committee. OpenBao’s postgresql storage backend turns any PostgreSQL cluster into its encrypted key-value store, and CloudNativePG turns that cluster into a self-healing, synchronously replicated, certificate-authenticated Postgres instance with no cloud database dependency underneath it.

This recipe deploys a three-instance CNPG cluster as OpenBao’s storage backend and removes every password from the connection: the schema-owning role and the application role OpenBao itself uses both authenticate with a DatabaseRole-issued TLS client certificate, enforced by explicit pg_hba rules rather than by the absence of a password. pg_hba.conf is PostgreSQL’s client-authentication file, the thing that actually decides, per connection, whether a role needs a certificate, a password, or nothing at all.

Setting up a local test environment with cnpg-playground

Nothing about this recipe is specific to any one Kubernetes distribution: any conformant cluster with enough worker capacity will do. To follow along locally, though, the official cnpg-playground repository is the fastest path to one, since it is pre-configured with the CloudNativePG operator already. It is designed primarily around CNPG’s own demos, so it is worth knowing what it actually gives you: a single Kind cluster with six nodes, a control plane node, one node labelled for infrastructure workloads, one labelled for application workloads, and three carrying a node-role.kubernetes.io/postgres taint. That taint is exactly what our Cluster‘s tolerations in Step 1 target, and it is also what leaves OpenBao itself with only the two general-purpose nodes to schedule onto, which matters once pod anti-affinity enters the picture in Step 3. setup.sh provisions one Kind cluster per argument it is given, normally used to model separate regions; passing it a single, arbitrary label gives you one local cluster and skips the two-region disaster recovery demo entirely.

Prerequisites: Docker, Kind, Helm and kubectl.

# Clone the CNPG Playground repository

git clone https://github.com/cloudnative-pg/cnpg-playground.git

cd cnpg-playground

# 1. Provision a single local cluster labelled "openbao"

./scripts/setup.sh openbao

# 2. Deploy CloudNativePG, cert-manager, the Barman Cloud plugin and a

# ClusterImageCatalog only, skipping the demo databases

REQUIREMENTS_ONLY=true ./demo/setup.sh

Architecture blueprint

- Storage engine: OpenBao’s native postgresql storage backend, with ha_enabled = "true" for its HA lock table.

- Database cluster: a 3-instance CNPG cluster with quorum-based synchronous replication (method: any, number: 1, the default dataDurability: required) for zero-data-loss failover.

- Workload isolation: node selectors, tolerations and required zonal pod anti-affinity keep PostgreSQL on dedicated nodes across separate failure domains, following CNPG’s scheduling guidance.

- Authentication: passwordless mTLS via the DatabaseRole CRD’s clientCertificate block, for both the schema owner and the application role, enforced by explicit pg_hba rules.

Step 1: deploy the CNPG cluster, roles and database

The Cluster below points imageCatalogRef at the postgresql-minimal-trixie ClusterImageCatalog that REQUIREMENTS_ONLY=true ./demo/setup.sh already deployed in the previous step, rather than pinning an image tag directly: CNPG resolves it to the latest minimal PostgreSQL 18 image in that catalog, so a kubectl apply against the same manifest keeps picking up new patch releases as the catalog is updated, no Cluster edit required. It also declares synchronous replication, workload isolation, and the two pg_hba rules that force certificate authentication for both roles OpenBao will use. Two DatabaseRole objects follow: role-openbao, the schema owner used once to run DDL, and role-openbao-rw, the restricted role OpenBao itself connects as at runtime. Both get a clientCertificate, because a one-shot DDL job is no more entitled to a password lying around than the application is.

cnpg-stack.yaml

{{apiVersion: postgresql.cnpg.io/v1

kind: Cluster

metadata:

namespace: openbao

spec:

instances: 3

# Tracks the latest minimal PostgreSQL 18 image via the ClusterImageCatalog

# the playground's REQUIREMENTS_ONLY step already deploys.

# See https://cloudnative-pg.io/docs/current/image_catalog

imageCatalogRef:

apiGroup: postgresql.cnpg.io

kind: ClusterImageCatalog

major: 18

# See https://cloudnative-pg.io/docs/current/scheduling

affinity:

nodeSelector:

node-role.kubernetes.io/postgres: ""

tolerations:

- key: node-role.kubernetes.io/postgres

operator: Exists

effect: NoSchedule

enablePodAntiAffinity: true

topologyKey: topology.kubernetes.io/zone

podAntiAffinityType: required

postgresql:

# Synchronous replication: dataDurability defaults to "required", giving

# RPO=0 at the cost of pausing writes if no standby is available.

# See https://cloudnative-pg.io/docs/current/replication

synchronous:

method: any

number: 1

# The operator does not add cert rules for DatabaseRole client

# certificates automatically: without these, "openbao" and "openbao-rw"

# would fall through to the default scram-sha-256 rule, and since

# neither role has a passwordSecret, every connection would simply fail.

pg_hba:

- hostssl openbao openbao all cert

- hostssl openbao openbao-rw all cert

- hostnossl openbao openbao all reject

- hostnossl openbao openbao-rw all reject

# See https://cloudnative-pg.io/docs/current/postgresql_conf

parameters:

max_connections: '100'

log_checkpoints: 'on'

log_lock_waits: 'on'

hot_standby_feedback: 'on'

shared_memory_type: 'sysv'

dynamic_shared_memory_type: 'sysv'

storage:

size: 10Gi

---

apiVersion: postgresql.cnpg.io/v1

kind: DatabaseRole

metadata:

namespace: openbao

spec:

cluster:

clientCertificate:

enabled: true

databaseRoleReclaimPolicy: retain

---

apiVersion: postgresql.cnpg.io/v1

kind: DatabaseRole

metadata:

namespace: openbao

spec:

cluster:

clientCertificate:

enabled: true

databaseRoleReclaimPolicy: retain

---

apiVersion: postgresql.cnpg.io/v1

kind: Database

metadata:

namespace: openbao

spec:

owner: openbao

cluster:

}}

Apply these resources:

kubectl create namespace openbao

kubectl apply -f cnpg-stack.yaml

Watch for all three instance pods to come up, which takes a couple of minutes on a fresh cluster:

kubectl get pods -w -n openbao

Once all three are Running and Ready, confirm the cluster itself has reached a healthy state:

kubectl cnpg -n openbao status openbao-db

Cluster Summary

Name openbao/openbao-db

System ID: 7674399793927340061

PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:18.6-202608131513-minimal-trixie@sha256:e488b1434919f455f2ee4e18a181ce9b33f34cdd8dfb821126855486bce6ad34

Primary instance: openbao-db-1

Primary promotion time: 2026-08-15 23:10:49 +0000 UTC (3m15s)

Status: Cluster in healthy state

Instances: 3

Ready instances: 3

Size: 135M

Current Write LSN: 0/6000060 (Timeline: 1 - WAL File: 000000010000000000000006)

Continuous Backup not configured

Streaming Replication status

Replication Slots Enabled

Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority Replication Slot

---- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- ------------- ----------------

openbao-db-2 0/6000060 0/6000060 0/6000060 0/6000060 00:00:00 00:00:00 00:00:00 streaming quorum 1 active

openbao-db-3 0/6000060 0/6000060 0/6000060 0/6000060 00:00:00 00:00:00 00:00:00 streaming quorum 1 active

Instances status

Name Current LSN Replication role Status QoS Manager Version Node

---- ----------- ---------------- ------ --- --------------- ----

openbao-db-1 0/6000060 Primary OK BestEffort 1.30.0 k8s-openbao-worker3

openbao-db-2 0/6000060 Standby (sync) OK BestEffort 1.30.0 k8s-openbao-worker4

openbao-db-3 0/6000060 Standby (sync) OK BestEffort 1.30.0 k8s-openbao-worker5

Note the PostgreSQL Image line: a SHA-pinned, dated minimal build resolved straight out of the postgresql-minimal-trixie catalog, not a floating tag we wrote by hand.

Both standbys show up as Standby (sync) with a Sync State of quorum at the same time, which is exactly the dynamic behaviour method: any is meant to give: with number: 1, either standby satisfies durability, and CNPG does not pin a fixed “the” synchronous standby.

Once reconciled, the operator has created two client certificate secrets, role-openbao-client-cert and role-openbao-rw-client-cert, following its -client-cert naming convention. openbao, as the database owner, already has CREATE on the public schema by default (PostgreSQL grants that to the owner even though it revoked it from PUBLIC in v15), so no extra schema grant is needed before the DDL step.

Every manifest that mounts one of these secrets sets defaultMode: 0640 on the volume. Kubernetes mounts Secret volumes at 0644 by default, which libpq refuses outright: it rejects a private key file that is group-or-world-readable, whether owned by root (0640 or less) or by the connecting user (0600 or less). Since the mounted files stay root-owned and only their group matches the pod’s fsGroup, 0640 is the setting that satisfies libpq here, and it applies to every pod in this recipe that reads a client certificate, the schema-init Job and the OpenBao pods alike.

Step 2: initialise the schema and grant table privileges

DatabaseRole does not yet manage table-level grants: the permissions stanza that would let a Database object express GRANT/REVOKE declaratively is still an open proposal (#10826), as I covered when DatabaseRole first shipped in Recipe 25. Until that lands, a one-time Job running the DDL as the schema owner is the correct way to create OpenBao’s tables and grant the restricted DML the openbao-rw role actually needs.

OpenBao’s postgresql storage backend expects two tables when ha_enabled = "true": openbao_kv_store, with a parent_path, path, key and value column and a primary key on (path, key), and openbao_ha_locks, holding its HA lock records. Getting the key column or the primary key wrong here is an easy mistake, since OpenBao would otherwise silently create the table itself on first connection using its own DDL, and that path only works if the connecting role already has CREATE, which openbao-rw deliberately does not. Pre-creating both tables under the owner role and setting skip_create_table on the OpenBao side (Step 3) keeps that DDL entirely off the restricted runtime role.

The same job also closes a gap PostgreSQL leaves open by default: every database grants CONNECT to PUBLIC, and the public schema grants USAGE to PUBLIC too, so any role that can log into the cluster at all can connect to openbao and see what is in its public schema unless told otherwise. Making REVOKE CONNECT … FROM PUBLIC the default posture across every database CloudNativePG manages is on the roadmap (#10831), but it is not there yet, so the schema-init job revokes it explicitly here and grants back only what openbao-rw actually needs:

schema-init-job.yaml

{{apiVersion: batch/v1

kind: Job

metadata:

namespace: openbao

spec:

ttlSecondsAfterFinished: 300 # Clean up job 5 minutes post-completion

template:

metadata:

spec:

restartPolicy: OnFailure

securityContext:

runAsNonRoot: true

runAsUser: 26

fsGroup: 26

seccompProfile:

type: RuntimeDefault

containers:

- name: psql-init

image: ghcr.io/cloudnative-pg/postgr

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。

Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend