CloudNativePG: managed-role passwords exposed via pg_stat_statements, enabling command execution in the DB pod

Impact

The operator wrote role passwords in cleartext into the CREATE ROLE / ALTER ROLE statements it issued, so with pg_stat_statements preloaded and track_utility on, any tenant holding pg_monitor or pg_read_all_stats could read platform-managed superuser and application-owner passwords out of the statement history. With those credentials and superuser TCP access enabled, the tenant reconnects as superuser and runs operating system commands inside the database pod via COPY ... FROM PROGRAM. That is a shell in a pod on the cluster, with whatever service account token and mounted secrets that pod carries - on a GPU cluster this typically means the Postgres instance backing scheduler, metering or model-registry state, shared across tenants. Clusters whose managed-role Secrets carry SCRAM-SHA-256 verifiers rather than plaintext passwords were not affected.

Who can reach it

An authenticated database user on a CloudNativePG-managed cluster who holds pg_monitor or pg_read_all_stats, on an instance where pg_stat_statements is preloaded with track_utility enabled. No cluster-level Kubernetes access is needed to read the passwords.

What to do

Upgrade the operator to 1.28.4, 1.29.2 or 1.30.0; the operator upgrade rolls the managed instances, so expect a restart of each Postgres pod rather than a node action. Patching alone is not sufficient - any password that was already in a statement history must be rotated, and managed-role Secrets should be moved to SCRAM-SHA-256 verifiers so the operator never handles a plaintext password again.

References