IAM Role

An IAM Role is an AWS identity that you create with specific permissions but without permanent credentials. Instead of being associated with a single person, a role can be assumed by anyone or anything that needs it - an EC2 instance, a Lambda function, a user in another AWS account, or even an external identity provider.

When a principal assumes a role, AWS Security Token Service (STS) issues temporary credentials (access key, secret key, and session token) that expire automatically. This is fundamentally more secure than long-term access keys because there is nothing to leak or rotate.

Common Use Cases

• EC2 Instance Roles: give applications on EC2 access to AWS services without embedding credentials
• Cross-Account Access: allow users in Account A to access resources in Account B
• Lambda Execution Roles: define what AWS services a Lambda function can call
• Federation: let users from an external IdP (Okta, Azure AD) assume a role via SAML or OIDC

Security Best Practices

• Always prefer roles over long-term access keys
• Use condition keys to restrict who can assume the role (e.g., aws:SourceIp, aws:PrincipalOrgID)
• Set the maximum session duration to the minimum needed
• Use external ID for cross-account roles to prevent the confused deputy problem

Anatomy of a Role: Two Policies, Two Questions

Every role answers two separate questions with two separate documents. The trust policy (also called the assume role policy) answers "who may become this role": it names the principals allowed to call sts:AssumeRole, plus any conditions such as an external ID or an organization ID. The permissions policies answer "what can this role do once assumed". Security reviews that only look at permissions miss half the picture: a modest read-only role trusted by the whole world is a bigger problem than a powerful role nobody external can assume.

Session mechanics are worth knowing precisely. A role's MaxSessionDuration can be set between 3600 seconds (1 hour, the default) and 43200 seconds (12 hours), and the caller requests a duration within that cap via --duration-seconds (minimum 900 seconds). When one role assumes another (role chaining), the session is capped at one hour regardless of settings.

How It Goes Wrong in Practice

The classic misconfiguration is the over-broad trust policy. Someone sets the trust principal to an entire AWS account root ARN, or worse, to "AWS": "*", intending to "sort it out later". A trust policy with a wildcard principal makes the role assumable by any AWS account on the internet, and attackers routinely scan for such roles: role ARNs are guessable, assumption attempts are free, and a hit hands the attacker legitimate temporary credentials inside your account with whatever permissions the role carries. The related failure is a third-party integration role without an external ID condition, which enables the confused deputy scenario: another customer of the same vendor tricks the vendor's infrastructure into assuming your role.

The second pattern is privilege escalation through iam:PassRole. A principal that can launch EC2 instances or create Lambda functions and pass an arbitrary role effectively inherits the permissions of the most powerful role it can pass. Always constrain iam:PassRole to specific role ARNs.

Practical Check: Read the Trust Policy

Audit who can assume a role before worrying about what it can do:

aws iam get-role --role-name payments-deploy

The output includes the AssumeRolePolicyDocument (URL-encoded JSON), MaxSessionDuration, and RoleLastUsed, which tells you the Region and date of the role's last activity, useful for spotting abandoned roles. To test assumption end to end:

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/payments-deploy --role-session-name audit-check

Both --role-arn and --role-session-name are required; the response returns the temporary access key, secret key, session token, and expiration.

Frequently Asked Questions

What is the difference between a role and an IAM user?

A user has long-term credentials that live until someone rotates them. A role has no credentials at all until it is assumed, at which point STS mints short-lived ones. That is why AWS guidance is roles for workloads and Identity Center for humans, with IAM users as a legacy exception.

Can a role assume another role?

Yes, this is role chaining, and it works across accounts. The important constraint: chained sessions are limited to a maximum of one hour, even if the target role allows 12-hour sessions.

How do I revoke a role session that is already active?

You cannot delete an issued token. Practical containment is to attach a deny policy to the role with a condition on aws:TokenIssueTime, which invalidates sessions issued before that moment, then fix the trust policy that allowed the assumption.