REFERENCE GUIDE

Role assumption, trust policy, and session scope

Assuming a role exchanges one identity context for a temporary session governed by a trust policy and permissions.

Also known as: STS · AssumeRole

role-assumptioncloud

Mechanism

Assuming a role exchanges one identity context for a temporary session governed by a trust policy and permissions. The caller must satisfy the trust relationship and any applicable caller-side authorization. External IDs, MFA, source identity, tags, and organization conditions can narrow who may obtain the session.

Practical method

Identify the caller and target role. Read the trust policy separately from the role permission policies. Map every condition to the actual request context. In the authorized lab, obtain a bounded session and verify its identity and one harmless permitted action.

caller authorization + role trust conditions -> session
session permissions remain constrained by its policies and limits

Interpreting evidence

A successful assume-role operation establishes session acquisition. Impact depends on the effective permissions of that session, not the role name.

Pitfalls and limits

Trusting an account principal does not always mean trusting every identity unconditionally. Session policies can reduce permissions. Chained role sessions have distinct duration limits and context propagation rules.

Sources & further reading

  1. Role trust and assumption ↗aws

Content license: CC-BY-4.0. Source-derived sections retain their cited licenses and redistribution notices. How this reference is compiled →