Is it secure to store the cert/key on a private AMI?

Question

Are there any major security implications to bundling a private AMI which contains the private key/certificate & environment variables?

For resiliency I'm creating an EC2 image which should be able to boot and configure itself without any intervention. After boot it will attempt to:

• Attach & mount specific EBS volume(s)
• Associate a specific Elastic IP
• Start issuing backups of the EBS volume(s) to S3

However, to do this it will need the private key/pem files and will need certain environment variables to be available on start-up. Since this is a private AMI I'm wondering if it will be "safe" to store these variables/files directly in the image so that I don't need to specify any user-data information and can therefore start a new instance remotely (from my iPhone, if needed) should the instance be terminated for any reason.

Answer 1

A private AMI is safe, I wouldn't worry about anyone hacking your S3 data. However, a running server is as safe as you made it and you should assume that it is hackable. Therefore, your keys, which are really the key to Everything on your account, should not be left lying around.

Make sure that the startup scripts delete the keys from the disk and do not retain them, unless there is a really good reason.

If your server uses other AWS services and needs the keys to access them, consider having multiple AWS accounts for various services, and consolidate their billing for your convenience.

You can also use external management services like RightScale, Scalr or Eucalyptus.

Answer 2

I know this question is long dead, but a new feature of AWS has arisen (mid-2012) that provides a better answer than was previously possible. I found it very helpful and thought future searchers might also.

You no longer need to store any keys on an AWS instance in order for code on that instance to be able to make AWS calls. You can now leverage IAM Roles (announced here) to grant AWS permissions instead of locally storing private keys or certs. Roles are applied to instances at launch, and provide secure token-based access to Amazon services. These are ephemeral, automatically-rotating tokens, stored in environment variables and not on disk, so I believe this would be the most secure way to handle the original requirements.

This does not apply to general SSH keys you may have need of within a Linux environment, but those wouldn't be tied to your AWS account(s) anyway and should be managed separately. Roles just mediate your access to Amazon Services.

One nice thing about Roles is that you have to assign them at instance launch, but you can change what they are capable of at any time. For the example given, you could grant the instance Role the ability to map an EIP, mount EBS volumes and write to a specific S3 bucket, then add the ability to create and poll SQS queues later if the need arises without having to change anything on the instance.

Answer 3

AMIs which are directly stored in S3 will be encrypted by Amazon and signed with your keys (see "The creation process for an AMI that uses an instance store as its root device does the following:" in http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?ComponentsAMIs.html).

However, AMIs stored in EBS volumes are based on snapshots, which are not encrypted: aws.amazon.com/ec2/faqs/#Do_you_offer_encryption_on_Amazon_EBS_volumes_or_snapshots

In either case, you should take a critical look at the permissions on the S3 bucket containing your AMI. By default the bucket will only be accessible by your account, but you may also want to add further protection using S3 ACLs.

Answer 4

I can't really think of a more secure way to do it, since a private AMI is protected by the same AWS levels of security as your EC2 account.

An alternative would be to store the keys in a source code repository and check them out when you start up the EC2 instance; although you're then sending the keys across the wire, you can encrypt the traffic(e.g. with svn:ssh or https for Subversion).