"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)
