An application running on an EC2 instance needs to call AWS APIs. The security team requires that no long-lived access keys ever be stored on the instance. Which approach satisfies this requirement?
- Attach an IAM role to the EC2 instance through an instance profile, so the application retrieves short-lived credentials automatically from the instance metadata service
- Create an IAM user, generate an access key pair, and embed the keys in the instance's user data script
- Create an IAM user and have a developer manually enter its access key ID and secret access key into the application's configuration file
- Store the AWS account root user's access keys in an environment variable on the instance
Why A? And why not the others?
Correct answer: A. Attach an IAM role to the EC2 instance through an instance profile, so the application retrieves short-lived credentials automatically from the instance metadata service
An IAM role attached to an EC2 instance through an instance profile lets the application on that instance retrieve automatically-rotated, short-lived credentials from the instance metadata service, so no access key ever needs to be written to disk, checked into a script, or typed in by a person. This directly satisfies a no-long-lived-keys requirement. The option involving an IAM user's keys embedded in user data is wrong because that key pair is a static, long-lived credential that persists in the instance's configuration and does not expire on its own, which is exactly what the security team wants to avoid. The option involving manual entry of an IAM user's keys is wrong for the same reason: the credential is still long-lived and additionally now depends on a human handling and storing a secret. The option storing root user keys is wrong on every count: root credentials are long-lived, unrestricted in scope, and AWS explicitly recommends never generating or using root access keys for applications at all.
Source: AWS IAM documentation: IAM roles for Amazon EC2