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) or EKS Pod Identity — one IAM role per Kubernetes service account, instead of every pod on the node sharing the node's instance profile | Pod identity webhook / EKS Pod Identity Agent |
| 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
Service-Linked Roles: a role predefined by an AWS service (e.g., AWSServiceRoleForConfig for AWS Config) with a trust policy and permissions you can't edit. IAM deletes one only after the service no longer depends on it — disable the service (or remove its resources) first, then delete the role.
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.
Enforcing IMDSv2 at scale: An SCP that denies ec2:RunInstances unless ec2:MetadataHttpTokens is required (or an EC2 declarative policy for IMDS defaults) governs new launches only. Instances already running need detection — the AWS Config rule ec2-imdsv2-check — plus remediation that calls ModifyInstanceMetadataOptions with HttpTokens=required, typically a Config remediation action running an SSM Automation runbook.
⚠️ 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?
