Users have long-term keys. Roles have none. A role is a set of permissions that an identity can assume for a while, receiving temporary credentials that expire on their own. Almost everything that is not a human typing uses a role.

Two policies

aws iam create-role --role-name auditor --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name auditor --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

A role has a trust policy, which says who may assume it, and permission policies, which say what it may do once assumed. Both are needed. The trust policy is resource-based, so it has a Principal:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::123456789012:user/admin" },
    "Action": "sts:AssumeRole"
  }]
}

The Principal can be a user, a whole account (arn:aws:iam::123456789012:root, which then also needs an Allow on the caller's side), or a service such as ec2.amazonaws.com or lambda.amazonaws.com.

Assuming a role

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/auditor --role-session-name audit

The answer holds temporary credentials: a key id starting with ASIA, a secret, a session token, and an expiry. Put them in the environment and every following command runs as the role:

export AWS_ACCESS_KEY_ID=ASIA…
export AWS_SECRET_ACCESS_KEY=…
export AWS_SESSION_TOKEN=…
aws sts get-caller-identity

"Arn": "arn:aws:sts::123456789012:assumed-role/auditor/audit"

The ARN says sts, assumed-role, the role name and your session name. The session can read (ReadOnlyAccess) and nothing more; aws s3 mb fails. unset the three variables to be admin again.

Why roles