Recently, we connected an RDS proxy to our RDS PostgreSQL cluster.
Then we changed the host url in the secret from the cluster endpoint to the RDS endpoint.
We noticed that the secrets were not rotated then.
I then copied the code of the function and added some debug messages.
The following errors came to light:
[ERROR] SQL-CONNECTION-ERROR: SCRAM authentication requires libpq version 10 or above
[ERROR] SQL-CONNECTION-ERROR: FATAL: This RDS Proxy requires TLS connections
It would be great if the function could also handle the proxy.
EDIT:
The SCRAM and TLS problems are gone, by updating the lambda.
Now the problem is, that during the rotation the new generated secret has been created as "pending".
Then the password from "pending", will be set in the database and the function checks, if the connection will work, with the new password.
At this point the function fails, because the rds proxy, will only read the credentials for the user, from the "current" version from the secret.
Maybe you can find a good practice for that, that the function can handle rotations via rds proxy.
Recently, we connected an RDS proxy to our RDS PostgreSQL cluster. Then we changed the host url in the secret from the cluster endpoint to the RDS endpoint. We noticed that the secrets were not rotated then.
I then copied the code of the function and added some debug messages. The following errors came to light:
It would be great if the function could also handle the proxy.
EDIT:
The SCRAM and TLS problems are gone, by updating the lambda. Now the problem is, that during the rotation the new generated secret has been created as "pending". Then the password from "pending", will be set in the database and the function checks, if the connection will work, with the new password. At this point the function fails, because the rds proxy, will only read the credentials for the user, from the "current" version from the secret.
Maybe you can find a good practice for that, that the function can handle rotations via rds proxy.