STS and AssumeRole
Lesson 1 of 4 in Temporary Credentials.
Every temporary credential in AWS comes out of one service. AWS STS hands back a triple — an access key id, a secret access key, and a session token — with an expiry stamped on it. The session token is what makes it temporary: a request signed without it is rejected, and after the expiry the whole triple is inert.
The design goal is that nothing long-lived exists to steal. An EC2 instance profile, a Lambda execution role, an ECS task role, a federated console session, a CI pipeline — all of them are STS sessions underneath, refreshed by the SDK before they lapse. The exam's standing preference follows from that: when a scenario offers you an access key, look for the role.
Before the operations, the structural fact this whole domain rests on. A role has two policies, and they answer different questions:
- The trust policy (the role's resource-based policy) answers who may assume me. Principals, the
sts:actions they may call, and conditions. It grants nothing inside the account. - The permissions policy (identity-based, attached to the role) answers what the session may do once it exists.
Mixing them up is the single most productive distractor in Domain 4. "Add s3:GetObject to the trust policy" is always wrong. "Add the external account to the permissions policy" is always wrong.
| Operation | Caller holds | Session length | The identifying detail |
|---|---|---|---|
AssumeRole | AWS credentials (IAM user or another role) | 15 min → the role’s maximum session duration (default 1 h, ceiling 12 h); 1 h max when chaining | The general case: same-account or cross-account role assumption. Carries |
AssumeRoleWithSAML | A signed SAML 2.0 assertion — no AWS credentials | Up to 12 h, from the assertion’s | Enterprise workforce federation straight to IAM. Needs an IAM SAML identity provider. Cannot subsequently call |
AssumeRoleWithWebIdentity | An OIDC identity token — no AWS credentials | Up to 12 h | Machine and app identity from outside AWS: CI pipelines, mobile apps, EKS service accounts. Security lives in trust-policy conditions on token claims. |
GetSessionToken | An IAM user’s long-term credentials | Up to 36 h for an IAM user (default 12 h); 1 h for root | Re-issues the same permissions as a temporary, optionally MFA-validated session. It does not switch identity — the tell is "the CLI needs to satisfy an MFA condition". |
GetFederationToken | An IAM user’s credentials (or root; not a role) | Up to 36 h for an IAM user (default 12 h) | A custom identity broker minting credentials for a federated user. A session policy is required, and the result is the intersection of it and the calling user’s permissions. |
AssumeRoot | Management-account or IAM delegated-administrator credentials | 15 min (default and maximum) | One scoped privileged root task in a member account, named by a task policy ARN. Requires centralized root access; the global STS endpoint is not supported. |
Three properties of a session are worth separating, because questions pivot on them.
Duration. The role carries a MaxSessionDuration from 1 to 12 hours; the AssumeRole call may ask for anything from 15 minutes up to that, and fails if it asks for more. GetSessionToken and GetFederationToken run on their own scales. And chaining overrides all of it: a session obtained with role credentials may not exceed one hour. When a stem says "the job runs for six hours and the credentials expire after one", the answer is nearly always "it is chaining", not "raise the ceiling".
Attribution. A role session name is chosen by the caller and can be anything, so it is not evidence. sourceIdentity is: set it on the assume-role call (both the caller's identity policy and the role's trust policy must allow sts:SetSourceIdentity), and it cannot be changed or removed for the life of the session — including through further chaining. It appears in every CloudTrail event the session produces. "Shared role, but we must know which human acted" is the sourceIdentity question.
Scope. The session's permissions are the role's permissions, narrowed by any session policy and by any permissions boundary on the role. Nothing passed at assume time can add permission — a rule covered in full in Session policies and session tags.
Key terms: AWS STS (Security Token Service), AssumeRole, Role trust policy, Maximum session duration, Role chaining, sourceIdentity
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.