You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are converting from CloudFormation to Terraform. We create a secret with username and password in AWS Secrets Manager, then create a RDS DB instance (not cluster), then use the secret target attachment to attach the secret to the DB instance. This then results in AWS populating the secret with additional information.
Then, we use a rotation schedule and lambda to update the secret. Because the secret is attached to the DB instance, it automatically changes the DB instance's password to match.
Use a local file that keeps track of the date. Then use the file contents as a keeper for a random string resource. But, because the local file's contents are not known until after apply, it forces downstream resources to update every time.
Use formatdate("YYYY-MM", timestamp()) as a keeper for the random string resource. But this too is not known until after apply.
Change the secret rotation lambda so that it can directly change the password of the DB instance. Rather than only changing the secret, and expecting that to get propagated to the DB instance. This is currently considered too costly, although we may have to do it later.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
ghost
locked and limited conversation to collaborators
Aug 13, 2019
This issue was closed.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current Terraform Version
Use-cases
We are converting from CloudFormation to Terraform. We create a secret with username and password in AWS Secrets Manager, then create a RDS DB instance (not cluster), then use the secret target attachment to attach the secret to the DB instance. This then results in AWS populating the secret with additional information.
Then, we use a rotation schedule and lambda to update the secret. Because the secret is attached to the DB instance, it automatically changes the DB instance's password to match.
The example given here for "Creating a Secret and an RDS DB Instance" is basically what we have in CF: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-secrettargetattachment.html
Attempted Solutions
Attempted solutions:
keeper
for a random string resource. But, because the local file's contents are not known until afterapply
, it forces downstream resources to update every time.formatdate("YYYY-MM", timestamp())
as akeeper
for the random string resource. But this too is not known until afterapply
.Proposal
New resource type:
aws_secretsmanager_secret_target_attachment
- supporting all features described here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-secrettargetattachment.htmlAlso a new input for
aws_db_instance
taking a secret's ID / ARN, to implicitly create the secret target attachment.References
The text was updated successfully, but these errors were encountered: