What's the best method for passing AWS credentials as user data to an EC2 instance?

You can store the credentials on the machine (or transfer, use, then remove them. ).

You can store the credentials on the machine (or transfer, use, then remove them. ) You can transfer the credentials over a secure channel (e.g. Using scp with non-interactive authentication e.g. Key pair) so that you would not need to perform any custom encryption (only make sure that permissions are properly set to 0400 on the key file at all times, e.g. Set the permissions on the master files and use scp -p) If the above does not answer your question, please provide more specific details re. What your setup is and what you are trying to achieve.

Are EC2 actions to be initiated on multiple nodes from a central location? Is SSH available between the multiple nodes and the central location? Etc.

EDIT Have you considered parameterizing your AMI, requiring those who instantiate your AMI to first populate the user data (ec2-run-instances -f user-data-file) with their AWS keys? Your AMI can then dynamically retrieve these per-instance parameters from http://169.254.169.254/1.0/user-data. UPDATE OK, here goes a security-minded comparison of the various approaches discussed so far: Security of data when stored in the AMI user-data unencrypted low clear-text data is accessible to any user who manages to log onto the AMI and has access to telnet, curl, wget, etc.(can access clear-text http://169.254.169.254/1.0/user-data) you are vulnerable to proxy request attacks (e.g. Attacker asks the Apache that may or may not be running on the AMI to get and forward the clear-text http://169.254.169.254/1.0/user-data) Security of data when stored in the AMI user-data and encrypted (or decryptable) with easily obtainable key low easily-obtainable key (password) may include: key hard-coded in a script inside an ABI (where the ABI can be obtained by an attacker) key hard-coded in a script on the AMI itself, where the script is readable by any user who manages to log onto the AMI any other easily obtainable information such as public keys, etc. Any private key (its public key may be readily obtainable) given an easily-obtainable key (password), the same problems identified in point 1 apply, namely: the decrypted data is accessible to any user who manages to log onto the AMI and has access to telnet, curl, wget, etc.(can access clear-text http://169.254.169.254/1.0/user-data) you are vulnerable to proxy request attacks (e.g. Attacker asks the Apache that may or may not be running on the AMI to get and forward the encrypted http://169.254.169.254/1.0/user-data, ulteriorly descrypted with the easily-obtainable key) Security of data when stored in the AMI user-data and encrypted with not easily obtainable key average the encrypted data is accessible to any user who manages to log onto the AMI and has access to telnet, curl, wget, etc.(can access encrypted http://169.254.169.254/1.0/user-data) an attempt to decrypt the encrypted data can then be made using brute-force attacks Security of data when stored on the AMI, in a secured location (no added value for it to be encrypted) higher the data is only accessible to one user, the user who requires the data in order to operate e.g. File owned by user:user with mask 0600 or 0400 attacker must be able to impersonate the particular user in order to gain access to the data additional security layers, such as denying the user direct log-on (having to pass through root for interactive impersonation) improves security So any method involving the AMI user-data is not the most secure, because gaining access to any user on the machine (weakest point) compromises the data.

This could be mitigated if the S3 credentials were only required for a limited period of time (i.e. During the deployment process only), if AWS allowed you to overwrite or remove the contents of user-data when done with it (but this does not appear to be the case.) An alternative would be the creation of temporary S3 credentials for the duration of the deployment process, if possible (compromising these credentials, from user-data, after the deployment process is completed and the credentials have been invalidated with AWS, no longer poses a security threat. ) If the above is not applicable (e.g. S3 credentials needed by deployed nodes indefinitely) or not possible (e.g. Cannot issue temporary S3 credentials for deployment only) then the best method remains to bite the bullet and scp the credentials to the various nodes, possibly in parallel, with the correct ownership and permissions.

I don't want to bundle the credentials in the instance since I want users of my AMI to use their own AWS credentials. Once an instance boots, it will connect to S3 buckets and SQS queues specified by the user who starts the instances. SCP works OK for a few machines but not 10 or 100.

For loops? Meh – AdamK Mar 13 '09 at 19:47 OK, so you are providing an AMI to an arbitrary number of users, where each user will have to provide its own AWS credentials in order to connect to (your? Their?) S3 area?

– vladr Mar 13 '09 at 20:55 Vlad, the 'parameterizing your AMI' article is almost how I am currently doing things now. Actually, blogs.sun.Com/ec2/entry/… is even closer. The problem is user-data in my case is sensitive (AWS creds) and the password must be contained in the AMI.

– AdamK Mar 13 '09 at 21:23 You architecture still makes very little sense to me. Please edit the original article to clarify who is "I" in "I send the credentials", what is the password 'secrets' doing there and why it is so indispensable, etc. – vladr Mar 13 '09 at 0:05 1 You can make user-data inaccessible to anybody but root by either firewalling or blackholing the 169.254.169.254 ip address. Root can regain access, but ordinary users can not.

– Nakedible Mar 13 '09 at 6:50.

I wrote an article examining various methods of passing secrets to an EC2 instance securely and the pros & cons of each. shlomoswidler.com/2009/08/how-to-keep-yo....

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.