Isn't it a very bad practise to have to give your AWS credentials as user data when giving configuration for using S3_PING?. AWS documentation has this to say about launch data security:
Although only your specific instance can access launch data, the data is not protected by cryptographic methods. You should take suitable precautions to protect sensitive data (such as long lived encryption keys).
I would say it's not the best practice. Many people are doing this in that way. Of course this isn't an excuse for us.
AWS credentials passed in UserData field are not only used for S3_PING. We need that data to query AWS metadata server for running instances to register nodes. From the beginning of JBoss Cloud (previous CirrAS name) we injected AWS credentials in that way.
Isn't there any other way to handle this? For example, encrypting the credentials and storing the key for decypting it in the AMI.
Unfortunately this isn't so simple. We decided to injecting in that way because we wanted just run the nodes and have a cluster. Encrypting and decrypting doesn't make sense, because in that case every user would need to have management appliance with own key used for decryption bundled with it but we're providing just one, generic AMI.
We can consider that after launching nodes someone needs to log in to management appliance and start the management service passing valid credentials. If you're worried about this issue, please create a ticket.
Of course if you have better idea, we would love to hear it!
I was thinking how to protect user-data and instance metadata from user processes. For example one might deploy malicious JBoss AS application that reads user-data to steal credentials. What I came up with is the following:
iptables -I OUTPUT -d 169.254.169.254 -m owner ! --uid-owner 0 -m tcp -p tcp --dport 80 -j REJECT --reject-with icmp-host-prohibited
This allows only root to access this data. This solution relies on two assumptions:
- user doesn't kill firewall
- EC2 does not provide another means to access user data
I don't find this solution ideal but I can't think of anything more reliable and at the same time not require AMI customization.