IAM Roles and Instance Profiles

IAM roles are identities with temporary security credentials, unlike IAM users with long-term credentials. A role trust policy defines who can assume the role.

A trust policy is a JSON document specifying the Principal (who can assume the role) and the Action (typically sts:AssumeRole). For example, allowing an EC2 service to assume a role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

When an EC2 instance assumes this role, it receives temporary credentials (access key, secret key, session token) that are automatically rotated. This eliminates the need to store long-term access keys on instances.

AssumeRole API is used programmatically to assume a role. A CLI command like aws sts assume-role --role-arn arn:aws:iam::123456789012:role/CrossAccountRole --role-session-name Session1 returns temporary credentials. Applications use these credentials to access resources in the target account.

External IDs add a layer of protection for cross-account role assumptions. When a third party assumes your role, require an external ID to prevent the confused deputy problem. The external ID is a unique identifier that the third party must provide, ensuring they are the intended entity assuming the role.

Roles are the preferred way to grant permissions to AWS services, applications, and users in other accounts. They provide temporary credentials that expire automatically, reducing the risk of credential leakage.

Cross-account access allows users or services in one AWS account to access resources in another. Roles are the primary mechanism for cross-account access.

Cross-Account Role Assumption involves two accounts: the trusting account (resource owner) and the trusted account (requestor). The trusting account creates a role with a trust policy allowing the trusted account to assume it. The trusted account's users assume the role using STS AssumeRole.

For example, a company with a centralized logging account (Account A) allows application accounts (Account B and C) to write logs. Account A creates a LogWriter role with a trust policy allowing accounts B and C to assume it. Applications in B and C assume this role to write logs.

Organization Cross-Account Access simplifies management using AWS Organizations. Instead of specifying individual account ARNs in trust policies, use the organization root ARN to allow any account in the organization to assume the role. This scales better than managing individual account ARNs.

Role Chaining occurs when you assume a role and then assume another role. Role chaining has a 1-hour session duration limit and cannot be refreshed. Plan role chains carefully to avoid session expiration issues.

Session Policies restrict the permissions of assumed roles. When assuming a role, you can pass a session policy that further limits what the temporary credentials can do. This is useful for providing scoped access for specific tasks without modifying the role's permanent policies.

Instance profiles and execution roles provide AWS credentials to services without storing long-term keys.

EC2 Instance Profiles wrap an IAM role and attach to an EC2 instance. The instance automatically receives temporary credentials through the instance metadata service. Applications on the instance retrieve credentials by calling the metadata endpoint at http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.

For example, an EC2 instance hosting an application that reads from S3 and writes to DynamoDB assumes a role with s3:GetObject and dynamodb:PutItem permissions. The application uses the SDK, which automatically retrieves credentials from the instance metadata. No access keys are stored on the instance.

Security best practice: Use IMDSv2 (Instance Metadata Service Version 2) which requires a session token for metadata requests, preventing SSRF attacks that could steal credentials from IMDSv1.

Lambda Execution Roles grant Lambda functions permission to access AWS services. A Lambda function that reads from an SQS queue and writes to DynamoDB needs a role with sqs:ReceiveMessage and dynamodb:PutItem. The execution role also provides the basic Lambda execution permission for CloudWatch Logs.

Lambda Resource-Based Policies control who can invoke the Lambda function. Combined with the execution role (what the function can do), these provide a complete security model: resource policies control invocation, execution roles control actions.

EC2 Instance Role Limits: An instance can have only one IAM role. If the function needs access to multiple services, create a single role with permissions for all required services.

AWS services use roles to interact with other services on your behalf. Understanding the different role types prevents configuration issues.

Service-Linked Roles are created automatically by AWS services when you enable a feature that requires cross-service access. For example, enabling Amazon GuardDuty automatically creates a service-linked role that allows GuardDuty to read CloudTrail logs and VPC Flow Logs. You cannot manually create, modify, or delete service-linked roles; the service manages their lifecycle.

Service Roles are roles that you create and attach to an AWS service. Unlike service-linked roles, you define the trust policy and permissions. For example, when you configure an ECS task execution role, you create a role that allows the ECS service to pull container images from ECR and write logs to CloudWatch.

Linked Roles (or assumed roles by services) occur when a service assumes a role you created. AWS Elastic Beanstalk, for instance, can assume a role you provide to access S3 buckets during deployment.

Common Pitfalls:

• Deleting a service-linked role before disabling the associated feature causes errors
• Some services require specific permission boundaries on their service roles
• Service roles may need to be recreated if you modify the trust policy incorrectly

When debugging service access issues, check:

1. Does the service have a role configured?
2. Does the role's trust policy allow the service principal?
3. Does the role's permission policy include the required actions?
4. Are there any explicit Deny statements overriding the Allow?