Open gchristidis opened 10 months ago
Voting for Prioritization
Volunteering to Work on This Issue
I'm experiencing same issue, it fails on plan and is not deferred to apply phase.
Having the same issue as well. Imported a DB that was created outside of Terraform. Plain fails with the error aforementioned, but succeeds if the we introduce a change that calls for the DB to be replaced. seems like the TF doesn't plan to create the managed master password for an existing DB
same issue
A workaround:
join("", aws_db_instance.db.master_user_secret.*.secret_arn)
I'm facing this problem as well, but also get following error
╷
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for
│ <redacted>.aws_iam_policy.<redacted>
│ to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for
│ .policy: was
│ cty.StringVal("{\"Statement\":[{\"Action\":[\"secretsmanager:GetSecretValue\"],\"Effect\":\"Allow\",\"Resource\":[\"arn:aws:secretsmanager:*:<redacted>:secret:/\"],\"Sid\":\"GetSecretValue\"}],\"Version\":\"2012-10-17\"}"),
│ but now
│ cty.StringVal("{\"Statement\":[{\"Action\":[\"secretsmanager:GetSecretValue\"],\"Effect\":\"Allow\",\"Resource\":[\"arn:aws:secretsmanager:<redacted>:<redacted>:secret:rds!cluster-<redacted>\"],\"Sid\":\"GetSecretValue\"}],\"Version\":\"2012-10-17\"}").
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
Terraform Core Version
1.5.3
AWS Provider Version
5.22
Affected Resource(s)
Expected Behavior
Accessing master_user_secret[0] attributes should be deferred until after apply when changing manage_master_user_password=true on an aws_db_instance
Actual Behavior
Plan fails Accessing master_user_secret[0] as there is no elements in the list on the current aws_db_instance
Relevant Error/Panic Output Snippet
No response
Terraform Configuration Files
Steps to Reproduce
Create instance with a specified password
terraform apply -var known_password=known_pass123
and it will created the RDS instance with the known password, create a secret to hold the known password credentials and create the SSM parameter with the ARN of the known password secret.Now update the instance to use managed master password by using the default value for known_password
terraform apply
and the plan fails with the errorThe other direction works fine, you can create an RDS instance with managed master password
terraform apply
and then update it to using a known_passwordterraform apply -var known_password=known_pass123
and it updates as expected.Debug Output
No response
Panic Output
No response
Important Factoids
This test snipped is a simplified example of what we have but shows the issue. Our RDS instances have their passwords set by a Terraform variable and we want to move them to RDS managed, in either case the Master Secret ARN needs to be in an SSM parameter for and so this makes this impossible.
I have worked around the issue by using an aws_db_instance data source to read aws_db_instance.db.identifier, meaning the data source read is deferred until after apply and using that in the SSM parameter value. Using the data source to reread the instance after modification allows the change to be applied both ways as the SSM parameter calculation is deferred.
References
No response
Would you like to implement a fix?
None