IAM Roles and Assuming Roles

IAM roles are one of the most powerful and widely used features in AWS security. Unlike IAM users, which have permanent credentials, roles provide temporary security credentials that automatically expire. This makes roles inherently more secure and flexible.

---

What is an IAM Role?

An IAM role is an AWS identity with specific permissions, but it has no permanent credentials (no password, no access keys). Instead, when someone or something assumes a role, AWS issues temporary security credentials — an access key ID, a secret access key, and a session token — that expire after a configurable period (from 15 minutes to 12 hours).

Think of a role as a hat you can put on. When you wear the hat, you gain its powers. When you take it off, those powers go away.

---

Why Use Roles Instead of Users?

Concern	IAM User	IAM Role
Credentials	Permanent (must be rotated manually)	Temporary (auto-expire)
Credential theft risk	High — stolen keys work indefinitely	Lower — stolen keys expire quickly
For AWS services	Not recommended (requires embedding keys)	Best practice (no embedded keys)
Cross-account access	Requires sharing credentials	Secure delegation via trust
Federation	Not suitable	Ideal for external identity providers

---

Components of a Role

Every IAM role has two key components:

1. Trust Policy (Who Can Assume It)

The trust policy is a JSON document that defines which principals are allowed to assume the role. It answers the question: "Who can put on this hat?"

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

This trust policy allows the EC2 service to assume the role.

2. Permissions Policy (What the Role Can Do)

The permissions policy is a standard IAM policy attached to the role. It defines what actions the role is authorised to perform — just like policies attached to users or groups.

---

Common Use Cases for Roles

EC2 Instance Roles

When an application running on an EC2 instance needs to access other AWS services (e.g., reading from S3 or writing to DynamoDB), you should use an instance role — never hard-code access keys.

You create an instance profile (a container for the role) and attach it to the EC2 instance. The AWS SDK running on the instance automatically retrieves temporary credentials from the instance metadata service.

# The SDK automatically uses the instance role — no keys needed
aws s3 ls s3://my-bucket

Lambda Execution Roles

Every Lambda function must have an execution role. This role grants the function permissions to interact with other AWS services. When Lambda runs your function, it assumes this role and passes the temporary credentials to your code.

Cross-Account Access