Deploying OpenBao with a CloudNativePG PostgreSQL Backend on Kubernetes

OpenBao now supports a native PostgreSQL storage backend powered by a three‑node CloudNativePG (CNPG) cluster, eliminating passwords in favor of mTLS‑based client certificates. This shift lets AI, cloud, DevOps, and security engineers run a fully open‑source secret store on any conformant Kubernetes cluster without vendor‑locked cloud databases.

Architecture Overview

The stack consists of:

• OpenBao configured to use its postgresql storage type with ha_enabled = "true" for high‑availability lock tables.
• CloudNativePG delivering a three‑instance PostgreSQL 18 cluster with synchronous replication (method: any, number: 1) and built‑in pod anti‑affinity across zones.
• Certificate‑based authentication enforced by explicit pg_hba.conf rules for the schema‑owner role (openbao) and the runtime role (openbao-rw).

All components run on a Kind‑based test cluster created by the cnpg-playground scripts, but the manifest is distribution‑agnostic.

Deploying the CNPG Cluster

After provisioning a Kind cluster labelled openbao, the required operators are installed with a single script that sets REQUIREMENTS_ONLY=true. The CNPG manifest references a ClusterImageCatalog named postgresql-minimal-trixie, which points to the latest minimal PostgreSQL 18 image. Because the manifest uses the catalog reference, future patch releases are picked up automatically without editing the Cluster resource.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: openbao-db
  namespace: openbao
spec:
  instances: 3
  imageCatalogRef:
    apiGroup: postgresql.cnpg.io
    kind: ClusterImageCatalog
    name: postgresql-minimal-trixie
    major: 18
  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:
      method: any
      number: 1
    pg_hba:
    - hostssl openbao openbao all cert
    - hostssl openbao openbao-rw all cert
    - hostnossl openbao openbao all reject
    - hostnossl openbao openbao-rw all reject
    parameters:
      max_connections: '100'
      log_checkpoints: 'on'
      log_lock_waits: 'on'

The pg_hba entries guarantee that only TLS‑authenticated connections succeed; any non‑TLS attempt is rejected.

Configuring Passwordless mTLS for OpenBao

Two DatabaseRole resources are created: role-openbao (schema owner) and role-openbao-rw (runtime role). Both include a clientCertificate block, which the CNPG operator translates into a TLS certificate stored in a Kubernetes secret. OpenBao’s connection string references the secret, so no passwordSecret is required.

Because the roles lack password secrets, the default scram-sha-256 rule would block connections. The explicit pg_hba rules added above override that default, ensuring the certificate‑only flow works.

Operational and Security Implications

Running OpenBao on top of a self‑healing CNPG cluster provides several practical benefits:

• Self‑healing storage: PostgreSQL pods are automatically rescheduled on healthy nodes, preserving secret availability without external DB services.
• Zero‑password credentials: Eliminating passwords reduces secret sprawl and the risk of credential leakage.
• Zone‑aware anti‑affinity: PostgreSQL instances are spread across failure domains, improving resilience against node or zone outages.
• Vendor independence: The stack relies only on CNCF projects, avoiding lock‑in to managed cloud databases.

Operators must monitor the CNPG health checks and ensure the TLS certificates issued for the DatabaseRoles are rotated before expiration. The synchronous replication setting means writes pause if a standby is unavailable, so capacity planning for standby nodes is essential.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Adopting the OpenBao‑CNPG pattern gives you a fully open‑source, password‑less secret store that can survive node failures and does not depend on external cloud services. Evaluate your cluster’s zone topology and ensure you have sufficient standby capacity to avoid write stalls. Incorporate certificate rotation into your secret‑management lifecycle, and treat the CNPG operator as the single source of truth for both database and OpenBao storage health.