-
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
Encrypt State on save/load #29272
Comments
An alternate solution (which I'm proposing here to make it visually distinct, would be to only encrypt "sensitive" things, where the user can select (or override) what they consider sensitive. It just seems much more complicated to implement. For example: main.tf
terraform.tfstate result
|
MotivationIt's sometimes tough to limit access to a remote container, because administrators may already have full access to a cloud environment. If the state is stored inside the cloud, then there is no way to protect these administrators from fetching these passwords. Even when security is breached, then all state is out in the open. By protecting the state with a password that isn't stored in the same cloud, security is hardened. Implementation suggestionTo keep things simple, you should just encrypt the entire state. I would implement this functionality in the back-end provider, because some backends may also use some additional encryption where keys can be stored inside a vault. This would also make the implementation much easier. Let's consider the Azure back-end provider. You can specify secret value that is hashed to a 256-bit AES encryption key. This encryption key is used to decrypt the state in client.go:50 and used to encrypt the state in client.go:95. That would be all there is to it. I would be happy to provide the implementation for the Azure provider. The back-end configuration would then look something like:
Of course, it must be possible to fetch the |
For remote state, there is an open pull request that works for all backends. See #9556 |
@StephanHCB Let's close this one in favor of a PR that works for almost all storage backends. It's a shame that maintainers don't respond to the PR at all... |
@StephanHCB I love your PR, it's far better than what I could have come up with. I've Approved it, but I'm not sure if that's at all meaningful, since I'm not a maintainer. For reference, here's the PR: #28603 |
It would be very nice to add encryption to the state file, especially for local state files, or repo controlled state files. I'm happy to lend a hand to implement it myself, if you like.
Current Terraform Version
3.52.0
Use-cases
People who want to be secure, and not have sensitive info written down on their local disk or written to the S3 (or other) state backends. For those who repo-control their state, to protect it from nefarious actors (similarly to ansible-vault).
Attempted Solutions
I went here and found out it wasn't supported: https://www.terraform.io/docs/language/state/sensitive-data.html
Proposal
My vision for it was simply like, in the main.tf, have a line, something like:
Or some other place, and then, when you run terraform for the first time, it asks you "hey what password do you want?" Maybe it gives you some sass if your password is "password", maybe it asks you to repeat the password to make sure you typed it right.
Then, when saving the state, it simply encrypts it with a key derived from that password then saves that binary data as base64, so that it is friendly for transmission and doesn't confuse the heck out of text editors/git/terminals/etc. (similar to ansible-vault).
Then, when you run it a second time, it asks "what password did you use last time?" and uses that password to decrypt the state.
References
This one is similar, but my idea was more generic. So even if, for example, one was using the "encrypt at rest" functionality of S3, you could still do extra encryption on top of that, so that the data that S3 encrypts serverside is pre-encrypted, and any future backend that doesn't support encrypted data would also get encryption.
#28957
The text was updated successfully, but these errors were encountered: