4.2.2. Instance Profiles, Service Roles, and Execution Roles
First Principle: Every compute resource needs AWS credentials to interact with other services. Using IAM roles (not access keys) ensures credentials are temporary, automatically rotated, and scoped to exactly the permissions the workload needs.
Role Assignment by Compute Type:
| Compute | Role Mechanism | How Credentials Are Delivered |
|---|---|---|
| EC2 | Instance Profile (wraps an IAM role) | Instance metadata service (IMDS) |
| ECS | Task Role | ECS credential provider (container metadata) |
| EKS | IAM Roles for Service Accounts (IRSA) | Pod identity webhook |
| Lambda | Execution Role | Lambda runtime environment |
Best Practices:
- One role per workload: Don't share roles between unrelated applications
- Least privilege: Start with zero permissions and add only what's needed
- Use Access Analyzer: Identify roles with unused permissions and tighten them
- Enforce IMDSv2: Require Instance Metadata Service v2 (session-based) to prevent SSRF-based credential theft from EC2
IMDSv2 Security:
IMDSv1 allows any HTTP GET to 169.254.169.254 to retrieve credentials — an SSRF vulnerability in your application can steal EC2 role credentials. IMDSv2 requires a PUT request to get a session token first, which most SSRF exploits can't perform.
⚠️ Exam Trap: If a question describes an SSRF vulnerability on EC2 being used to steal credentials from the metadata service, the answer involves enforcing IMDSv2 (which blocks token-less credential requests).
Scenario: A penetration test reveals that an application on EC2 has an SSRF vulnerability. The tester demonstrates retrieving the instance profile credentials via http://169.254.169.254/latest/meta-data/iam/security-credentials/. You mitigate by enforcing IMDSv2 using instance metadata options (HttpTokens: required).
Reflection Question: Why does IMDSv2's session token mechanism specifically prevent SSRF-based credential theft while still allowing legitimate applications to use instance metadata?
