Letting CloudNativePG generate and rotate passwords could remove a recurring credential-management task. But what happens to a running application when the database password changes?

The feature preview published on October 24, 2026, for CloudNativePG 1.31 makes that question concrete. Following a password from generation to a fresh connection reveals both the automation available and the work applications still need.

As checked on October 25, 2026, version 1.31 remains unreleased. The implementation PR merged on October 23, 2026, while the latest published release is 1.30.1. The behavior below concerns development code; experiments belong in a disposable environment.

DatabaseRole takes responsibility for password creation

CloudNativePG 1.30 introduced DatabaseRole, a standalone Kubernetes resource for a PostgreSQL role. Giving each role its own lifecycle and status makes it easier to maintain alongside application configuration. CloudNativePG 1.30 release notes

The change intended for 1.31 adds spec.password.mode: generate. The operator creates a password and stores it in a Secret it manages, bringing credential creation into the role declaration.

The default Secret name is <DatabaseRole-name>-password, with username, password, and pgpass entries. If another system supplies the credential, mode: secret reads its Secret instead. Choose based on which system should generate and update the password. Development password-management documentation

duration and renewBefore separate lifetime from renewal time

Generation and scheduled rotation are separate choices. Omitting duration creates a password without scheduling its replacement. Implementation PR

With a compatible development operator and an existing app-db cluster in the same namespace, the configuration can take this form. This is a documentation-based example, not a reported execution result.

apiVersion: postgresql.cnpg.io/v1
kind: DatabaseRole
metadata:
  name: app-login
spec:
  cluster:
    name: app-db
  name: app_login
  login: true
  password:
    mode: generate
    duration: "720h"
    renewBefore: "24h"

Here, 720 hours is 30 days and 24 hours is one day, making renewal due roughly 29 days after issuance. That day is not an overlap period during which both passwords work. PostgreSQL holds one password per role; applying the replacement prevents new connections from authenticating with the old value. Rotation documentation

The generated password deadline also reaches PostgreSQL through VALID UNTIL. This expires password authentication, not the role itself, and does not govern authentication methods that do not use passwords. PostgreSQL CREATE ROLE documentation

If renewal stops, the credential does not remain usable indefinitely. The availability consequence is that new connections can fail once the deadline passes, making expiration part of operational planning.

Delivering an updated Secret requires application participation

Changing the password does not immediately terminate established sessions. A consumer holding the old value encounters trouble when opening another connection. There can also be a short interval between updating the Secret and applying its value to the database. Connection behavior in Recipe 28

Kubernetes delivery adds another boundary. Secret values supplied as environment variables do not update inside a running container; a restart is required. Reading the environment again on reconnection therefore does not retrieve the replacement. Kubernetes credential-distribution guide

A normal Secret volume receives file updates eventually, rather than immediately. A Secret mounted through subPath does not receive automatic updates. Secret volume update behavior

Even with files, establish whether the application or connection pool rereads the credential before opening a connection. Testing retries that reload it is a practical response to possible database and delivery delays. This is an operational recommendation derived from those mechanisms, not a guarantee of uninterrupted service.

Test manual rotation through to a fresh connection

The cnpg.io/rotatePassword annotation lets you request rotation without waiting for a long renewal cycle. With the namespace containing the example role selected, use:

kubectl annotate databaserole app-login cnpg.io/rotatePassword=now
kubectl get databaserole app-login -o yaml
kubectl describe databaserole app-login

The first command requests a password change. The others expose deadline information in status.password and the recorded events. Do not interpret disappearance of the annotation alone as success: distinguish PasswordRotated from PasswordRotationIgnored. Manual rotation documentation

Then retrieve credentials through the same delivery path as the application and open a new connection. Checking established sessions and fresh connections separately helps locate delays in Secret generation, database application, or credential delivery.

Reversing the configuration also requires attention to ownership. Switching from generate to secret deletes the generated Secret; merely naming that same Secret does not transfer ownership. First copy the credential into a differently named Secret you manage. Mode-transition documentation

Readiness for automatic rotation depends on more than choosing a renewal interval. Once the application can reconnect with the updated credential, password lifecycle management can become part of the role declaration. Building that complete validation path is useful preparation while awaiting the stable release.

Source

• Title: Gabriele Bartolini: CNPG Recipe 28 - Generated and rotating PostgreSQL user passwords in CloudNativePG 1.31
• URL: https://postgr.es/p/9zS