Terraform-provider-aws: Support for RDS/Redshift Password Removal after Creation from State

[ccslamstack]

When creating an RDS instance or Redshift Cluster the plaintext password gets stored in the state file. This is insecure as the state is plain text json. Can you create an option to omit the passwords from the state file after successful creation or update of these resources.

Our typical procedure now is to create the resource, then having to state rm the resource and re-import it from terraform code w/o the password field. This is a pain for work flow and not storing plain text passwords in git/state files. These features would be wonderful!!!

[radeksimko]

Hi @ccslamstack
as mentioned in https://www.terraform.io/docs/state/sensitive-data.html#recommendations we list some recommendations on how to address sensitive values in the state. For most use cases we discourage from storing state files in version control system and use remote state instead.

The last paragraph also mentions future work which will more likely involve encrypting fields, rather than removing them. Terraform works with state and it is there to allow full recreation of the resource when necessary. Removal of any parts of the state is intentionally difficult because it's not something we want/expect users to do.

[ccslamstack]

Why store the password in the state file at all. It's not something that gets returned via the API, why not auto remove it from the state file after the resource is created? The data gets stored in the state file and per corporate policies must be removed in a lot of cases at an enterprise level, whether Encryption at Rest via S3 is being used. This should really be optional with RDS/Redshift to remove the resource/reimport it w/o the password upon successful creation. We're having to do this manually now which is a huge pain for automation and git workflows via state rm and imports. It would be nice if there was a feature to not have the password in the state at all since it's not returned via the API and won't affect the resource. We're an Enterprise customer requesting this , and have worked with the same scenario over at another Enterprise as well, where keeping stored secrets in the state is just not possible via corporate policies. If this isn't something that can be done on your end, I'll consider patching it on our end, but I think for compliance standards would be a nice added feature for Enterprise, thanks!

[github-actions[bot]]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[krystan]

Going to have to second this, treating the state file as sensitive isn't really an option where passwords are concerned, same goes for private keys, usernames also are not ideal, it is very hard to defend corporately, in fact, some people have started questioning the whole tool because of this sort of thing which gets very tricky.