I have the following configuration in a Cloudformation template:
"MyRDSSecret": {
"Type": "AWS::SecretsManager::Secret",
"Properties": {
"Description": "Master secret for RDS instance",
"GenerateSecretString": {
"SecretStringTemplate": "{\"username\": \"postgres\"}",
"GenerateStringKey": "password",
"PasswordLength": 24,
"ExcludePunctuation": true
}
}
},
"Database": {
"Type": "AWS::RDS::DBInstance",
...
},
"SecretRDSInstanceAttachment": {
"Type": "AWS::SecretsManager::SecretTargetAttachment",
"Properties": {
"SecretId": { "Ref": "MyRDSSecret" },
"TargetId": { "Ref": "Database" } ,
"TargetType": "AWS::RDS::DBInstance"
}
}
I had just added "ExcludePunctuation": true
and updated my CF stack. Using the CLI aws secretsmanager get-secret-value
I confirmed that a new password had been generated that met the specs of the new config above. However, I am not able to login to my Postgres instance on RDS using that new password - I confirmed that in fact the old password was still in force in the database.
I found this GitHub issue from 2020: Updates to DB password via SecretManager does not work. It seems that if AWS::SecretsManager::SecretTargetAttachment
is not mutated, the password won't propagate to the DB - could that be the same issue here?
How do I update the password in the database after a change to my template forces a rotation?
I have not. I'm wondering if this is a bug - presumably if updating the SecretsManager resource generates a new password in the secret, that password should also be set on the database.
Is there no "hands off" approach to secret rotation? What's the point of the SecretsManager and all its configuration options if I have to write a lambda function myself to do the rotation?