Support AWS RDS: read pg_roles instead of pg_authid, and fix role updates for non-superuser admins

[wesselOC]

Problem

On AWS RDS, SELECT on pg_authid is denied to every role — including rds_superuser — so the operator failed with permission denied for table pg_authid (SQLSTATE 42501). Non-superuser roles on vanilla
PostgreSQL hit the same wall. Fixing the read alone turned out to be insufficient: two further RDS-specific failures blocked role updates entirely.

Changes

1. Reads moved off pg_authid to the public pg_roles view (RoleService)
   roleExists, roleLoginMatches, fetchCurrentFlags, and fetchCurrentRoleComment now read pg_roles, which is world-readable and masks only rolpassword. pg_roles was added to the jOOQ codegen and regenerated.

2. Password verification is privilege-aware (PostgreSQLAuthenticationService)
   checkPassword now probes has_table_privilege('pg_catalog.pg_authid', 'SELECT') (world-readable) before touching pg_authid. When the verifier can't be read it returns UNVERIFIABLE and the reconciler falls
   back to comparing the password Secret's metadata.resourceVersion against Role.status.appliedPasswordSecretVersion. This avoids raising 42501 inside the reconcile transaction, which previously aborted the
   transaction (25P02) and made the subsequent password-rotating ALTER ROLE silently fail.

3. ALTER ROLE emits privilege-gated attributes only when they change (RoleService.buildAlterRole)
   Previously every attribute token was asserted on each update. Since PG16, merely naming SUPERUSER/CREATEDB/CREATEROLE/REPLICATION/BYPASSRLS requires the executing role to hold it (only a superuser may name
   SUPERUSER), so a non-superuser RDS admin got permission denied to alter role on every update. These five attributes are now emitted only when they differ from the role's current state; INHERIT/CONNECTION
   LIMIT/VALID UNTIL remain asserted (not privilege-gated).

Security notes

• The tracked value in Role.status is the opaque, non-sensitive Kubernetes resourceVersion — no password-derived material is stored in etcd.
• Passwords continue to flow as bound parameters; identifiers via jOOQ quoting.

Testing

Adds restrictedConnection_passwordChange_isAppliedThroughTransaction, which rotates a password over a connection that cannot read pg_authid (reproducing RDS). It failed on both bugs above before the fix and
passes now. Full :operator:test is green except the two HelmTest cases, which fail only because the helm CLI isn't installed locally.

[ThoSap]

Duplicate of #71

Thanks for opening this PR, but I mentioned already in #70 (comment) that I will have a look at this.

Both PRs found the same two root causes, and they fix them the same way (most likely as you took #70 (comment) as the agent input):
The reads move to pg_roles, and ALTER ROLE names a privilege-gated attribute only when it changes. The two PRs differ in how they detect a password change without a read of pg_authid, and that is where I decided for #71.

What is missing here, or worse than in #71

• A rolled-back transaction can persist a password that PostgreSQL never stored. reconcileInTransaction calls status.setAppliedPasswordSecretVersion(...) inside the transaction lambda, right after alterRole. The membership grants and the comment update run after that point, in the same transaction. When one of them fails, the ALTER ROLE rolls back, but the mutated status object survives. BaseReconciler.handleError then patches exactly that status. The next reconcile sees a matching version, treats the password as applied, and never retries. The role keeps the old password for good. A missing ADMIN OPTION on a parent role triggers this, which is likely on the very non-superuser admin that this PR targets. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 sets the fingerprint only after dsl.transactionResult(...) returns, for this reason.

• resourceVersion answers a different question than "did the password change". Every edit to the Secret bumps it, a label or an annotation included, and each bump causes a needless password rewrite. An etcd restore or a cluster migration reassigns it and does the same. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 fingerprints the password itself, so it reacts to the password and to nothing else.

• The cleartext password still reaches the server. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 computes the SCRAM-SHA-256 verifier in the operator and sends only the verifier. The password therefore stays out of the server log, out of pg_stat_statements, and out of pgaudit. On a managed service the user often cannot control that logging at all. This part is independent of Rermission denied for table pg_authid (SQLSTATE 42501) on AWS RDS #70, and CloudNativePG does the same since v1.29.2.

• ALTER ROLE is still not minimal. This PR makes only the five privilege-gated attributes conditional. INHERIT, CONNECTION LIMIT, and VALID UNTIL stay asserted on every update. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 makes every option conditional, LOGIN included, and skips the statement when nothing differs at all.

• No user-facing documentation. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 documents the minimum admin privileges per Custom Resource, the PostgreSQL 16 ADMIN OPTION limit, the one-time password rewrite after the upgrade, the passwordEncryption field, and the threat model of the stored fingerprint.

• Narrower test coverage. The new tests cover the read path and one password rotation. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 adds a suite that drives the whole controller against a LOGIN CREATEDB CREATEROLE admin, through create, update, password rotation, the login toggle, membership, drop, and the error path for superuser: true.

• The PostgreSQL version claim in the description is not right. SUPERUSER, REPLICATION, and BYPASSRLS were superuser-only long before PostgreSQL 16. Reconcile Role resources with a non-superuser admin such as the master user of managed PostgreSQL cloud services #71 verified the denial on PostgreSQL 15 and on 18 with an explicit privilege matrix. The code here is still correct, only the reasoning is not.

One idea I liked

The has_table_privilege probe is a good idea. Where pg_authid is readable, it lets the operator compare the real verifier and repair a password that somebody changed directly in PostgreSQL.

I still decided against it for #71. It makes the behaviour depend on the privileges of the admin role: a superuser cluster takes one path, a managed service takes the other. That means two code paths to reason about, to test, and to support forever, and a bug report then needs the privileges of the admin role before anybody can read it. #71 keeps one path, so the operator behaves the same everywhere.

Thanks again for the analysis, tokens and for the time you put into this.

[ThoSap]

We should also no longer rely on pg_authid because of the sensitive password hashes, as it requires superuser privileges, and causes permission errors on managed cloud databases as you found out, making pg_roles the safer alternative in the long run and the approach #71 uses.

Using pg_authid was a bad design from my part, and now it is done in a proper way.

[wesselOC]

Thanks for resolving the issue in such quick time!