-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
Allow encryption of tfstate file #1421
Comments
Related #516 |
The obvious problem with encrypting the entire file is that we're not able to diff changes to the tfstate file. Perhaps the user could choose through configuration between either encrypting certain specific attributes, the file as a whole, or nothing at all. |
Encrypting the contents of the state db would provide encrypting the state for all storage (local/remote) - it would be nice to have this type of protection (especially because details like the RDS master password is sitting in plain sight..) when the state is stored in Consul or Atlas too. |
I'm not sure this is the solution you're looking for, but I have a PR open to allow S3 encryption of data while at rest (see linked issue above). @mitchellh would this be an acceptable solution, at least for the S3 part of the remote-config storage? |
https://github.com/TomPoulton/hiera-eyaml has inline encryption |
@woodhull not sure if you're still dealing with this issue, but if so, would encrypting tfstate files using git-crypt suffice? Attempting to run
|
We eventually settled on |
This comment was marked as off-topic.
This comment was marked as off-topic.
Thanks, @air3ijai |
We currently have a wrapper ruby script that decrypts the tfstate file before terraform apply runs and then encrypts the file after the run is complete.
We check the encrypted version into source control so the tfstate can be shared among the team, while storing and distributing the keys separately. We do not check in the unencrypted version of the tfstate file as it includes RDS passwords and other sensitive information. The unencrypted version is included in the gitignore file, but we keep it around so humans can inspect it.
It would be nice if each terraform user did not need to figure out how to wrap the terraform commands to manage secrets as we have, but instead there was a standard way of accomplishing this behavior.
The text was updated successfully, but these errors were encountered: