CloudNativePG 1.30: DatabaseRole CRD and Two CVE Patches

CloudNativePG 1.30.0 landed this week with three changes that matter for production Postgres-on-Kubernetes teams: a new DatabaseRole CRD that makes role management a proper GitOps citizen, a Lease-based primary election that cuts your failover window, and two CVE patches — one of which covers a privilege escalation with a path to in-pod RCE. The security fixes are backported to 1.29.2 and 1.28.4, so even if you skip the new features for now, patching is not optional.

Two CVEs — Start Here

Before the features, the security patches. CVE-2026-55769 is the one to take seriously. A database owner could plant overloaded operators in the public schema, then exploit the operator’s pooled connections to hijack query execution. The vector leads to in-pod RCE via COPY ... FROM PROGRAM. The fix pins search_path = pg_catalog, public, pg_temp on all of CNPG’s pooled connections, cutting off that path entirely.

CVE-2026-55765 is lower severity but still worth patching. The operator was issuing CREATE ROLE and ALTER ROLE commands with cleartext passwords, which meant the plaintext could surface in database logs or extension captures. The fix encodes passwords as SCRAM-SHA-256 before they ever reach a SQL command. Only the verifier hits the wire, not the secret.

Both CVEs are patched in 1.30.0, 1.29.2, and 1.28.4. Pick the patch that fits your current minor version and apply it now. The full release notes include the severity ratings and affected version ranges.

DatabaseRole CRD: Roles Graduate to First-Class Citizens

Before 1.30, PostgreSQL role management in CNPG lived inside the Cluster resource’s .spec.managed.roles stanza — mixed in with storage config, replication settings, and everything else. That worked for small setups, but it meant you couldn’t RBAC a single role definition, couldn’t track role changes in isolation, and couldn’t let teams own their own role manifests without touching the cluster spec.

The new DatabaseRole CRD fixes this by giving each role its own Kubernetes object: its own lifecycle, its own status conditions, its own RBAC controls, and its own reconciliation loop. Role definitions can now live in the same repository as the applications that use them. Migrating is straightforward — move an existing role stanza into a dedicated manifest and apply it.

apiVersion: postgresql.cnpg.io/v1
kind: DatabaseRole
metadata:
  name: app-reader
  namespace: my-pg-namespace
spec:
  cluster:
    name: my-cluster
  roles:
    - name: app_reader
      login: true
      comment: "Read-only application role"
  clientCertificate:
    enabled: true

The clientCertificate block is a notable addition. When enabled, the operator automatically generates and renews a TLS client certificate signed by the cluster’s CA and stores it as a Secret. Your application connects with a certificate instead of a password — no secret rotation, no credential management. The Secret gets cleaned up automatically when the role is removed or the feature is disabled. CNPG Recipe 25 walks through the full setup including passwordless TLS authentication end-to-end.

DatabaseRole joins the Database CRD that shipped in an earlier release. With both, you now have a genuinely composable Postgres-on-Kubernetes setup: clusters, databases, and roles all managed as independent objects with independent lifecycles. The old monolithic Cluster spec approach isn’t gone, but the architecture is clearly pointing away from it.

Lease-Based Primary Election: Faster Failover

The other headline change is operational rather than developer-facing. Before 1.30, when a primary node shut down, replicas had to wait for a timeout to expire before one could promote to take over. In practice this added seconds of unavailability that had nothing to do with actual replication lag — just bookkeeping delay.

CNPG 1.30 introduces a Kubernetes Lease object that acts as a mutex on primary status. The instance manager acquires the Lease before acting as primary and releases it on clean shutdown. When a healthy primary shuts down normally, the Lease releases immediately, and a replica can promote without waiting for the TTL to expire. You can tune the behavior through the new .spec.primaryLease stanza if your environment has specific timing requirements.

The practical effect is that planned maintenance failovers — rolling upgrades, node drains — get noticeably shorter. Unplanned crashes still run the full TTL path since there’s no clean release, but that’s expected behavior.

How to Upgrade

If you’re on Helm:

helm repo update
helm upgrade cnpg cnpg/cloudnative-pg \
  --namespace cnpg-system

If you manage the operator directly with kubectl:

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.30/releases/cnpg-1.30.0.yaml

Check the official Helm chart repository for the latest chart version. The upgrade is a two-step process under the hood: the controller updates first, then the instance manager in each PostgreSQL pod gets a rolling update. For large deployments, you can spread the instance manager rollout using the CLUSTERS_ROLLOUT_DELAY and INSTANCES_ROLLOUT_DELAY environment variables on the operator deployment.

CloudNativePG is growing up fast. This release — security hardening, declarative role management, smarter failover — reads less like a feature drop and more like a project that’s taken stock of what production deployments actually need. The PostgreSQL.org announcement has the full changelog if you want the complete picture before you upgrade.