Currently we are managing our RDS instance manually. We are trying to use terraform to manage our RDS instance. We imported the existing RDS configuration and not changing the passowrd. We still see that the master password is getting reset in the terraform plan and also in the RDS console events. We are not changing the master password and I was able to login using the same old password and so I wanted to know why the password is resetting even though we are not changing it.
these are changes that Terraform is changing and our only concern is the password change.
resource “aws_db_instance” “rds_db” {
+ apply_immediately = false
+ password = (sensitive value)
~ skip_final_snapshot = true → false
The password attribute of aws_db_instance is an unusual situation because the RDS API does not allow clients to read the current password value, and so the AWS provider can detect changes only by comparing to the value previously recorded in the Terraform state.
When you import into an aws_db_instance resource instance, the AWS provider cannot retrieve the current password and so it leaves it as null in the state. If your configuration specifies a non-null value for that attribute then the provider will notice that it’s no longer null and interpret that as you trying to set the password for the first time, as the plan diff suggests.
Of course we humans know that this is not an accurate description of the situation: an RDS instance always has a password, but the record of this object in the state doesn’t know what the password is and so the provider is reaching an incorrect conclusion about the situation.
If the value you set for password matches the currently-selected password in RDS then applying this plan should not cause a problem and should cause the password to then be tracked in the Terraform state so that this won’t occur again on the next plan.
An alternative way to fix it is to manually modify the state to reflect the current password. This is a risky maneuver because it requires editing the state snapshot format that is normally maintained exclusively by Terraform itself, and so you need to be careful not to change it in a way that Terraform would not accept. However, it’s okay to do it with some care. Here are the steps:
Tell your coworkers that they should not perform any Terraform operations for the duration, because you’re about to pretend to be Terraform and modify the state but other Terraform processes won’t know that and so could potentially publish new state snapshots while you are working.
Run terraform state pull >temp.tfstate to create a local copy of the latest state snapshot. I suggest also copying that temp.tfstate file to another filename so that you’ll have a local backup copy of the original state snapshot in case you need it to recover from a mistake.
Open that temp.tfstate file in your favorite text editor and find the JSON object describing aws_db_instance.rds_db. You should find the cached values for all of the other attributes of the object, but password will not be set for the reasons I described above.
Carefully edit that JSON object to include a "password" property whose value matches what you’ve assigned to that argument in the configuration.
Find the top-level "serial" property that typically appears near the start of the state snapshot. Its value should be an integer; change it to be the next consecutive integer. For example, if you find "serial": 3 then change it to "serial": 4.
Terraform uses this to confirm that you are intending to create a new state snapshot, as opposed to uploading a corrupted copy of the previous state snapshot.
Run terraform state push temp.tfstate to submit the updated file as a new state snapshot.
If you are able to complete this process without errors then you should find that terraform plan no longer proposes to change the password, because the AWS provider will find that the prior state matches the password value specified in your configuration.