[ladon86]

The short version is:

1) Create an S3 bucket. Remove all permissions from it

2) Create an IAM role - give it explicit read permissions to just that bucket (there's a HOWTO at the bottom of this article: http://mikeferrier.com/2011/10/27/granting-access-to-a-singl...). When you start an ec2 instance, you can give it one (and only one) IAM instance role.

3) Put your secrets or configs in a file on that bucket. For example, config.json or whatever format you choose.

4) On your instance or container, use the aws-cli on when your app starts to copy that file down from S3, then read it into memory in your application and then delete it.

It's a bit of a hack but you can now easily restrict access to that secrets bucket, and only your running instances/containers can access it. The secrets only exist in running app memory. Now don't allow SSH access to those instances :)

[austinjp]

I'm somewhat naive regarding S3. If data is in RAM, can you prevent it being swapped to disk and read by an unauthorised user?

(I guess "RAM" and "disk" are virtual entities, but hopefully the spirit of the question still applies.)

[ladon86]

As the sibling comment to mine points out, the fact that the instance has access to S3 means it's not actually secure - they could just use the aws-cli to copy the file back down again. My comment about deleting the file from disk was a bit silly and doesn't add any true security.

Really, you need to just make sure that the instance is secure. The point of this whole setup is not to make secrets unobtainable if someone compromises your app server; it is to prevent you from checking in production database passwords and secrets to your code repository.