6.4 Instance Profiles, Service Roles & Execution Roles for Compute

6.4 Instance Profiles, Service Roles & Execution Roles for Compute

Every compute workload that calls an AWS API needs credentials. Skill 3.2.2 tests whether you give them the right kind: temporary credentials from an IAM role, delivered by the platform, scoped to that workload, and never embedded in code, AMIs, container images, or environment files. Each compute service delivers role credentials differently, and most exam traps come from mixing them up.

---

The Roles Each Compute Service Uses

---

EC2 Instance Profiles and IMDS

An instance profile is a container for one IAM role. When it is attached, code on the instance retrieves short-term credentials from the Instance Metadata Service, and the credentials rotate automatically.

• Require IMDSv2. IMDSv2 requires a session token obtained with a PUT request (the token lifetime is 1 second to 6 hours) before metadata can be read, which blocks most server-side request forgery (SSRF) attempts to steal role credentials. Set HttpTokens to required on instances and launch templates, and enforce it with an SCP on the ec2:MetadataHttpTokens condition key or a declarative policy for instance metadata defaults.
• Control the hop limit. HttpPutResponseHopLimit of 1 stops containers that sit an extra network hop away from reaching IMDS, which forces them to use their own task or pod credentials.
• Detect credential theft. GuardDuty reports UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS (and .InsideAWS) when an instance's role credentials are used from somewhere other than that instance.
• Bind credentials to the network. The global condition keys aws:EC2InstanceSourceVPC and aws:EC2InstanceSourcePrivateIPv4 identify where instance credentials were delivered. Comparing aws:EC2InstanceSourceVPC with aws:SourceVpc in an SCP or resource policy lets instance credentials work only from their own VPC.

---

iam:PassRole: Who Can Hand a Role to a Service

Attaching a role to an EC2 instance, Lambda function, ECS task, or other service requires the caller to have iam:PassRole on that role. If a developer can pass any role, they can launch compute with an administrator role and run code as that role, which is privilege escalation. Restrict iam:PassRole to specific role ARNs or paths and use the iam:PassedToService condition:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::111122223333:role/app-roles/lambda-*",
  "Condition": {
    "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" }
  }
}

---

Service Roles, Service-Linked Roles & the Confused Deputy

• A service role is a role you create and control that a service assumes to act for you, such as a Glue job role or a Step Functions state machine role.
• A service-linked role is predefined by the service, linked to it, and not editable; SCPs don't restrict service-linked roles.
• When a service principal assumes your role on behalf of a specific resource, add aws:SourceArn and aws:SourceAccount conditions to the trust policy. This prevents the confused deputy problem, where another customer's resource tricks the service into using your role.

---

Lambda Execution Roles

The execution role grants the function's permissions. Lambda assumes it and injects the credentials as environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), so never log the environment. Separate this from the function's resource-based policy, which controls who may invoke the function. The execution role should include only the function's needs; functions attached to a VPC also need permissions to manage network interfaces (for example, the AWSLambdaVPCAccessExecutionRole managed policy).

---

ECS: Task Role vs Task Execution Role

This distinction appears on the exam often:

• The task role is what the application code in the container uses (for example, dynamodb:PutItem). Credentials come from the container credentials endpoint, not the EC2 instance profile.
• The task execution role is used by the ECS agent and Fargate to pull images from Amazon ECR, send container logs to CloudWatch Logs, and retrieve Secrets Manager or Parameter Store values referenced in the task definition.

If an application gets AccessDenied calling DynamoDB, check the task role; if the task fails to start because it can't pull an image or read a secret, check the task execution role.

---

EKS: Pod Identity and IRSA

Pods should never share the node's instance profile. Two mechanisms give each Kubernetes service account its own role:

Separately, EKS access entries map IAM principals to Kubernetes permissions through the EKS API (with access policies such as cluster admin or view), replacing hand-edited aws-auth ConfigMap entries.

---

Specialty Exam Pitfalls

1. Long-term keys in user data or images: Access keys baked into AMIs, containers, or user data are exposed to anyone who can read them. Use roles.
2. IMDSv1 left enabled: SSRF against an application can read instance credentials; require IMDSv2.
3. Unrestricted iam:PassRole: Lets users launch compute with privileged roles.
4. Confusing ECS roles: Application permissions belong in the task role, not the task execution role or the container instance's instance profile.
5. Pods using the node role: Without Pod Identity or IRSA, and with IMDS reachable, every pod inherits the node's permissions.