[jsfitzsimmons]

We ran into this problem with terraform and we needed a fix quickly. The problem is that they recommend you check in your .tfstate files, which does make sense; they do need to be synchronized between everyone who might be working on the repo. However, we learned later down the line that in some cases, the state files might contain secrets. So we rolled out git-crypt for all .tfstate files to future-proof ourself against accidental checkin of secrets.

Terraform does support a number of out of band state management backends that I would prefer to use, but none of those backends support encryption at rest. Hopefully hashicorp will roll out support for vault as a backend at some point...

[varikin]

Why not store your remote state in S3 buckets? They support encryption at rest.

[eamann]

S3's "encryption at rest" is transparent (see: http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-enc...). If someone (or some server) has access to the S3 bucket, they have access to all of the data. Control then is delegated to IAM roles and permissions, not to the crypto model.

> As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects.

The only advantage of S3 encryption is that if someone walks out of the data center with a disk, they can't read the data on it.

[JoshTriplett]

Then you need a different secret in the application: the key to the data in the S3 buckets.

Ultimately, you have to supply at least one secret to the application at runtime, and then it can bootstrap its way to others if needed.

[jonesetc]

All you need are the same IAM secrets that you already needed for terraform. Keeping the state out of repos and in encrypted buckets is definitely the way to go.