[mratzloff]

Well, you can use KMS to do something similar, but without the auto-rotation.

1. Use a KMS key to encrypt a secrets file (obviously, never check this into source control)

2. Store the encrypted secrets file in an S3 bucket

3. Tie a new IAM role with kms:Decrypt and s3:GetObject policies for the relevant resources to your EC2 instance

4. On app start, get the KMS key and secrets file, decrypt, and set environment variables

In practice, rotating using this scheme just means creating a new KMS key, re-encrypting the file and pushing the updated copy to S3, and updating the IAM role's kms:Decrypt policy. It's not too bad unless you have a million services.

[mattwad]

This seems like the easiest solution, and we've been pretty successful. We have sub-folders based on your environment and only machines have roles that can read production. We also realized you don't even have to encrypt and decrypt.. just turn on encryption for the S3 bucket, I believe it's the same thing.

[jeremya]

It's not exactly the same thing. Encryption at rest on S3 is good, but security is about layers. If you only use that, then you are one mis-configured S3 bucket policy away from exposing your secrets. Bad bucket policies are one of AWS' biggest footguns- plenty of intelligent people have done it before, don't assume it's a mistake you'll never make. It's so easy because S3 is a service that has to make publicly-accessible storage easy to achieve.

KMS keys on the other hand, do not have that use case. If the secrets in your S3 bucket have been encrypted using a KMS key (or better yet, a data key derived from a KMS key) and your bucket is compromised, your secrets are safe as long as the attacker cannot ALSO get access to the KMS key. By all means, enable encryption at rest on S3, but don't make that your only defense.