Zero-Trust Secrets: Running OpenBao on Kubernetes with CloudNativePG Passwordless Backend

A detailed technical implementation guide published by CNCF ambassadors and PostgreSQL maintainers outlines how to deploy OpenBao on Kubernetes backed by a three-instance CloudNativePG (CNPG) cluster in a completely passwordless configuration. The architecture pairs OpenBao's PostgreSQL storage backend with CloudNativePG's declarative `DatabaseRole` custom resource definition (CRD), enforcing mutual TLS authentication and strict PostgreSQL Host-Based Authentication (`pg_hba`) rules. This design eliminates both persistent local state on OpenBao pods and long-lived static secrets across the database connection pipeline. For platform and security engineers, managing the persistence layer of a centralized secrets manager has historically presented a circular dependency: how to authenticate the secrets manager to its storage backend without hardcoding credentials into manifests. While cloud provider managed databases offer IAM authentication, teams pursuing sovereign or multi-cloud infrastructure frequently faced operational lock-in. This pattern delivers an entirely open-source, self-healing foundation that satisfies strict zero-trust standards without tethering platform teams to proprietary cloud provider authentication APIs or commercial licenses. This development fits into the broader maturation of Kubernetes database operators and post-HashiCorp licensing pivots. Since the open-source fork of Vault under the Linux Foundation as OpenBao, adoption has hinged on robust operational blueprints that match or exceed legacy enterprise features. Concurrently, CloudNativePG has emerged as the premier cloud-native operator for mission-critical relational storage. Combining the two reflects the industry's shift toward declarative identity and automated certificate management directly embedded within the Kubernetes control plane. In practice, running this architecture introduces critical lifecycle considerations that engineers must plan for. Because OpenBao initializes its PostgreSQL connection pool at process startup, it does not dynamically reload client certificates when files change on disk. Although CloudNativePG automatically issues and renews 90-day client certificates approximately one week before expiration, platform teams must orchestrate automated rolling restarts of the OpenBao pods within that renewal window to avoid abrupt connection drops. Furthermore, teams must pre-create database schemas using privileged setup jobs while restricting OpenBao's application role permissions to prevent runtime initialization failures, ensuring strict separation of operational privileges.