DEVOURED
Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend
OpenBao combined with CloudNativePG offers a passwordless, self-healing, and vendor-neutral secret management stack on Kubernetes.
What: This setup uses synchronous PostgreSQL replication and certificate-based authentication (mTLS) to secure data without relying on cloud-native managed database services.
Why it matters: This approach reduces vendor lock-in and improves security posture by replacing static passwords with dynamic client certificates that integrate with Kubernetes.
Takeaway: When mounting TLS secrets for PostgreSQL, use `defaultMode: 0640` to ensure `libpq` correctly handles file permissions within Kubernetes pods.
Deep dive
- Deployment: Deploys a three-instance CloudNativePG cluster with synchronous replication for zero-data-loss failover.
- Auth Strategy: Uses DatabaseRole CRDs to enforce mTLS instead of passwords.
- Schema Lockdown: A one-time init job REVOKEs public schema permissions to ensure that only the OpenBao application role has access.
- Anti-Affinity: Uses Kubernetes pod anti-affinity and node selectors to keep PostgreSQL instances in separate failure domains.
- Certificate Lifecycle: CloudNativePG handles client certificate renewal, though OpenBao pods require rolling restarts to pick up the updated keys.
Decoder
- mTLS (mutual TLS): A security protocol where both the client and the server authenticate each other using digital certificates.
- pg_hba.conf: The configuration file that controls client authentication in PostgreSQL, deciding which hosts and users can connect and what authentication method is required.
- Taint/Toleration: Kubernetes mechanisms that allow nodes to repel specific sets of pods unless those pods explicitly 'tolerate' the taint.
Original article
Full article content is not available for inline reading.
Explore all 58 articles in today's digest
Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi