RDS resources with passwords always get destroyed / rebuilt

[dhobbs]

If you run terraform plan immediately after a clean terraform apply with an RDS resource, the presence of a password field causes terraform to report the following:

password: "" => "foobarfoobar" (forces new resource)

I'm guessing because the interrogation it does of running resources doesn't bring the password back.

[armon]

I wonder if this attribute should just be computed once then and never updated on read.

[ryanking]

It appears that the the password field is special-cased, so as to not keep it in the state file:

https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_db_instance.go#L192-L194

I just ran into this too. I assume this means no one is using terraform to manage RDS in a production environment?

[jlund]

I just ran into this as well.

@ryanking Interestingly, that special-casing is at odds with the documentation which states the following (emphasis added):

password - (Required) Password for the master DB user. Note that this will be stored in the state file.

Manually adding the plaintext password to the state file is a temporary workaround for the issue. Be sure to revert the change before committing though!

I'm glad that the password is not stored in the state file, and I'm happy to see that this was done by design in the code. Perhaps storing the password in the state file as a hash, or using scrypt, would be advisable. That way the password could still be compared to see if it has changed between runs, but it would not need to be stored in plaintext in order to do so.

[kubek2k]

Thats a general problem with passwords and confidential data in terraform. I think that would be a great idea to mark data as confidential in schema file, and store the hash of it in the state file. BTW - this problem also question the whole idea of putting the state file in version control.

@mitchellh ^ ?

[bronislav]

I also have this issue. Actually this particular issue stops me from using terraform for production. I have switched to Ansible, but completely unhappy with it.

[phinze]

It's worth noting that the RDS API's ModifyDbInstance operation supports updating the master password without replacing the whole DB Instance. Unfortunately it looks like mitchellh/goamz does not yet support that API call.

I too like @jlund's proposal that we store a hash of the password in the state file to detect changes. Then if we can add Update support to the aws_db_instance resource, we also won't have to force DB instance replacement for a password update.

[chipi]

+1 for this to get somehow solved. Maybe worth looking into how Ansible deals with confidential information through a concept of a vault

[phinze]

Alright the fix for this was just merged and should come out with 0.3.7! 💃

For now we are storing the password in plaintext in the state file and documenting that fact. Further discussion around the general topic of sensitive values in the state file can be found over at #516 .

[ipmb]

Thanks! 🎉

[djandruczyk]

This issue has re-appeared with TF 0.9.4
A new instance that was created with 0.9.4, is repeatedly destroyed.
terraform plan shows:
-/+ aws_db_instance.my_dev_db (tainted)
...
password: "" => "" (attribute changed)
..

[kc-dot-io]

@djandruczyk I'm also seeing this. Have you found a work around?

[ghost]

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.