Open woodhull opened 9 years ago
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? git-crypt
facilitates diffs. I've been using it for sharing encrypted tfstate and other files amongst teams.
Attempting to run terraform
before unlocking the repo via git-crypt
throws an error, which is useful feedback to an operator:
$ terraform plan
Decoding state file version failed: invalid character '\x00' looking for beginning of value
$ file terraform.tfstate
terraform.tfstate: data
$ git-crypt unlock
$ file terraform.tfstate
terraform.tfstate: ASCII text, with very long lines
We eventually settled on git-crypt
like so many others.
That was implemented in OpenTofu v1.7.0
State Encryption - Protect your precious state files with end-to-end encryption.
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.