New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RDS resources with passwords always get destroyed / rebuilt #689

Closed
dhobbs opened this Issue Dec 17, 2014 · 11 comments

Comments

Projects
None yet
@dhobbs

dhobbs commented Dec 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@armon

armon Dec 18, 2014

Member

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

Member

armon commented Dec 18, 2014

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

@ryanking

This comment has been minimized.

Show comment
Hide comment
@ryanking

ryanking Dec 19, 2014

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?

ryanking commented Dec 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jlund

jlund Dec 23, 2014

Contributor

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.

Contributor

jlund commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kubek2k

kubek2k Dec 23, 2014

Contributor

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 ^ ?

Contributor

kubek2k commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bronislav

bronislav Jan 9, 2015

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.

bronislav commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Jan 10, 2015

Member

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.

Member

phinze commented Jan 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chipi

chipi Jan 23, 2015

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

chipi commented Jan 23, 2015

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

bitglue pushed a commit to bitglue/terraform that referenced this issue Jan 28, 2015

Phil Frost
Fix aws_db_instance to not recreate each time
Several of the arguments were optional, and if omitted, they are
calculated. Mark them as such in the schema to avoid triggering an
update.

Go back to storing the password in the state file. Without doing so,
there's no way for Terraform to know the password has changed. It should
be hashed, but then interpolating the password yields a hash instead of
the password.

Make the `name` parameter optional. It's not required in any engine, and
in some (MS SQL Server) it's not allowed at all.

Drop the `skip_final_snapshot` argument. If `final_snapshot_identifier`
isn't specified, then don't make a final snapshot. As things were, it
was possible to create a resource with neither of these arguments
specified which would later fail when it was to be deleted since the RDS
API requires exactly one of the two.

Resolves issue hashicorp#689.
@phinze

This comment has been minimized.

Show comment
Hide comment
@phinze

phinze Jan 28, 2015

Member

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 .

Member

phinze commented Jan 28, 2015

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 .

@phinze phinze closed this Jan 28, 2015

@ipmb

This comment has been minimized.

Show comment
Hide comment
@ipmb

ipmb Jan 28, 2015

Thanks! 🎉

ipmb commented Jan 28, 2015

Thanks! 🎉

yahyapo pushed a commit to yahyapo/terraform that referenced this issue Mar 13, 2015

Phil Frost Yahya Poonawala
Fix aws_db_instance to not recreate each time
Several of the arguments were optional, and if omitted, they are
calculated. Mark them as such in the schema to avoid triggering an
update.

Go back to storing the password in the state file. Without doing so,
there's no way for Terraform to know the password has changed. It should
be hashed, but then interpolating the password yields a hash instead of
the password.

Make the `name` parameter optional. It's not required in any engine, and
in some (MS SQL Server) it's not allowed at all.

Drop the `skip_final_snapshot` argument. If `final_snapshot_identifier`
isn't specified, then don't make a final snapshot. As things were, it
was possible to create a resource with neither of these arguments
specified which would later fail when it was to be deleted since the RDS
API requires exactly one of the two.

Resolves issue hashicorp#689.
@djandruczyk

This comment has been minimized.

Show comment
Hide comment
@djandruczyk

djandruczyk May 5, 2017

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)
..

djandruczyk commented May 5, 2017

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)
..

@slajax

This comment has been minimized.

Show comment
Hide comment
@slajax

slajax Jun 7, 2017

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

slajax commented Jun 7, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment