An IAM role has no permanent credentials. Instead, a principal assumes it through STS and receives temporary credentials that expire. This removes long-lived access keys and makes cross-account access and least privilege practical.
Before you start
You should understand IAM policies and principals. This article covers role assumption and temporary credentials.
Step-by-step walkthrough
Step 1: Separate trust from permissions
A role has a trust policy, which says who may assume it, and permission policies, which say what the role may do. They answer different questions, and conflating them is a common source of over-permissive roles. The trust policy is the gate; the permission policy is the grant.
Step 2: Assume and receive temporary credentials
The principal calls sts:AssumeRole, and STS returns an access key, secret and session token with an expiry. The credentials are short-lived, so a leak has a bounded impact and rotation is automatic. Services such as EC2 and Lambda can assume a role without any stored key.
Step 3: Guard against the confused deputy
When a role trusts another account’s service, add conditions such as sts:ExternalId so that only the intended caller can assume it. Without a condition, a third party could be tricked into assuming the role on an attacker’s behalf.
Worked scenario
The trust policy allows a specific account to assume the role.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "abc-123" } }
}]
}Walk through the example
Only account 111122223333 may assume the role, and only when it presents the external id abc-123. The role’s permission policies then bound what the session may do. The session credentials expire, so access is temporary and auditable.
Common mistake
Creating long-lived access keys for a service instead of a role, which risks permanent exposure. Another is a trust policy without an external id, which enables the confused-deputy problem.
Verify the behavior
Assume the role and confirm the session credentials expire. Attempt assumption without the external id and confirm it is denied. Check CloudTrail for the AssumeRole event and the session identity.
Interview exercise
Why are temporary role credentials better than access keys?
Answer and reasoning
They expire, so a leak is time-bounded and no permanent secret exists to be found in code or a machine. They are scoped to a role, which can be least-privileged and audited, and they rotate automatically. Access keys never expire and, once leaked, remain valid until manually revoked.
Continue learning
Compare credential handling in Roles and temporary credentials and policy evaluation in IAM policy evaluation. Read the AWS IAM roles documentation and try the AWS interview questions.