Hacker News Reader

Comment by tptacek | Hacker News Reader

The "use IAM roles for EC2" recommendation is a bit sketchy. The current security zeitgeist, not just after Colin's post but also after DerbyCon and Black Hat, is that EC2 roles are dangerous and, when under attack, not very predictable.

View on HN

Using IAM roles for EC2 is far and away better than what beginners would otherwise do, which is create a set of permanent credentials and deploy it everywhere.

Do you have links to the DerbyCon and Black Hat talks? And could you clarify what "when under attack, not very predictable" means?

An attacker who compromises an EC2 instance can quietly grab the instance role credential and use it even after losing access to the instance itself.

"Have the application retrieve a set of temporary credentials and use them." "In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated for you." Attacker should only have access until creds are expired no ?

That's right. Instance store credentials have an expiration time of a few hours. However, if the instance policy is very open you could create yourself a new IAM account or use STS to maintain persistence after the generated credentials expire.

This is why it's important to lock down instance profiles to do only what the application needs to do and no more. For example, you may give the permission to s3:DeleteObject, and in the event that the box is compromised the attacker would be able to delete files in your S3 bucket. However, if you don't give access to s3:DeleteObjectVersion you can evict the attacker and restore the deleted objects with relative ease.

This is why I would not recommend giving access to s3:* to an instance profile (or indeed, any production credentials).

Thank you for the reply - that makes sense to me, least privilege seems to be the primary defense in that case. Having explicit creds you rotate yourself I could see having benefits as far as control, but also requires more work / potential for implementation mistakes.

Well, the AWS credentials auto-rotate. It does however provide a familiar place for an attacker to go to get the instance credentials, but that doesn't really help. At some point, those credentials must exist in plain-text for you to use them. If they're in a config file, they can be read out, if they're in RAM they can be pulled out with a debugger. At least if your box is temporarily owned due to a zero-day that you later patch, the credentials aren't going to be valid for long - although that situation would be hardly ideal!

You've also got to go to the trouble of getting the credentials on your box to start with. With instance roles, you can launch an instance and have it immediately capable of doing what your application needs. In the case of most applications my company runs, the instance profile is enough and no further security credentials are required. When database credentials are required, they're retrieved via S3, authenticated by the instance profile.

we use iam roles and credstash(dynamodb and kms) for retrieving database credentials. My comment was mostly in terms of the fact we cannot control the rotation for roles, say in the event of a breach like where someone committed keys to github and I can explicitly expire/rotate(assuming those keys were not themselves temporary and have not already expired :))

I believe you can actually [0]. In a production setting it's a lot harder to accidentally leak the credentials - my concern would be if someone compromised the instance or if it was tricked into opening the instance store up to the net, such as a badly configured nginx instance (how you'd do that accidentally though I have no idea)

[0] http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use...

Good point! slightly less granular than per key but still very helpful, thanks!

Can you elaborate on "when under attack, not very predictable"?

I would really, really appreciate if you would elaborate on this. Security seems to have the most unspoken community knowledge of anything I need to know.

Thanks for the comment. Added an issue with this thread: https://github.com/open-guides/og-aws/issues/98

If you'd like to PR or discuss there it'd def help us cover this better.

Thanks for the insight! Would you consider sending a pull request with a note on that?

Reply on news.ycombinator.com