Roles, trust policies, and PassRole

Who may assume whom — and the quiet escalator.

In short. IAM users with long-lived access keys do not scale and do not expire.

IAM users with long-lived access keys do not scale and do not expire. Roles do: a trust policy decides who may call sts:AssumeRole, a permissions policy decides what the session can do, and session duration caps how long a stolen temporary credential works. Most modern AWS identities you care about — EC2 instance profiles, Lambda execution roles, CI OIDC roles, cross-account break-glass — are roles.

The quiet escalator is iam:PassRole. Whoever can pass a powerful role to a service (EC2, Lambda, Glue) can often gain that role's power indirectly. Treat PassRole as carefully as you treat AdministratorAccess.

Trust policy vs permissions policy

Trust policies are resource policies on the role answering "who can assume me?" Permissions policies answer "what can a session do?" Confusing them produces roles nobody can assume or roles everyone can assume with empty permissions. Condition keys like aws:PrincipalArn, sts:ExternalId, and OIDC sub claims belong in trust policies for federation.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      },
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:acme/app:ref:refs/heads/main"
      }
    }
  }]
}

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/readonly --role-session-name lab
aws sts get-caller-identity

{
  "AssumedRoleUser": { "Arn": "arn:aws:sts::111122223333:assumed-role/readonly/lab" }
}

PassRole discipline

Grant iam:PassRole only on specific role ARNs to specific services via iam:PassedToService conditions where possible. A wildcard PassRole to * is often game over for account privilege boundaries.

Going deeper

Cross-account roles should use external IDs when third parties assume into you, and should prefer organization principal paths when assuming across your own accounts. Broad Principal: * with a weak condition is a public assume surface.

Session tags and transitive tags enable attribute-based access control — powerful and easy to get wrong. Start with static permissions; add tags when a real multi-tenant case demands them.

Inventory unused roles quarterly. Attackers love abandoned roles with trust still open to old partner accounts. Access Analyzer helps find external principals you forgot.

Name roles by function (payments-api-prod-read) not by person. Attach permissions via managed or carefully reviewed inline policies; avoid attaching AdministratorAccess "temporarily." Temporary becomes permanent under load.

Prefer AWS managed policies only when they truly match least privilege; otherwise copy into a customer managed policy you can trim. Broad managed policies are convenient starting points, not destinations.

Try this

Create a readonly role in a lab account, assume it, prove S3 list works and IAM create-user fails.

aws s3 ls
aws iam create-user --user-name should-fail || true

… buckets …
An error occurred (AccessDenied) …

Takeaway

Prefer roles with tight trust and permissions; treat PassRole as high risk; keep sessions short. Standing user keys are last-century AWS.

Next: OIDC from CI so pipelines never store AKIA keys again.

Related