Session Policies and Tag-Based Scoping

Sometimes you want to grant a role but restrict what a particular session can do without editing the role itself. Session policies and session tags let you shrink permissions at the exact moment a role is assumed. These advanced STS features support fine-grained, scalable least privilege that the exam rewards.

A session policy is an inline or managed policy passed to AssumeRole (via Policy or PolicyArns). It does not grant new permissions; it can only filter the role's existing permissions for that session. The effective permissions are the intersection of the role's policies and the session policy.

Because the result is an intersection, a session policy can never let a session do more than the role already allows. If the role grants s3:* but the session policy allows only s3:GetObject, the session can only get objects. This makes session policies a safe way to hand out a downscoped slice of a broader role.

A common use: a single powerful role is assumed by an orchestration tool that, for each job, attaches a session policy limiting that job to one bucket or one resource group. Each session is tightly scoped even though the underlying role is broad. This avoids creating dozens of narrowly tailored roles.

This CLI snippet shows passing an inline session policy that restricts the session further. The role must already permit these actions for them to take effect.

Session tags are key-value attributes attached to a session at AssumeRole time. Passed via the Tags parameter, they become part of the request context and can be read in policies through aws:PrincipalTag. Session tags carry attributes about who is assuming the role into every authorization decision.

Session tags are the backbone of Attribute-Based Access Control (ABAC) for assumed roles. A policy can require that the session's aws:PrincipalTag/Project equals the resource's aws:ResourceTag/Project, granting access only when the project tags match. One policy then serves many projects, scaling cleanly.

When roles are chained, ordinary session tags do not carry forward. Marking a tag as transitive makes it persist through subsequent role assumptions in the chain. This ensures attributes like the original user's department follow the identity across multiple hops, important for consistent ABAC.

Passing session tags requires the sts:TagSession permission in addition to sts:AssumeRole. The trust policy can also restrict which tag keys or values are allowed. Controlling who may set which session tags prevents users from granting themselves access by self-assigning privileged tag values.

Session policies and session tags work together: tags express who the session represents for ABAC matching, while session policies cap what the session may do. Together they let one broad role safely serve many tightly scoped sessions, the kind of elegant, scalable design the exam highlights.

Use session policies to intersect and shrink a role's permissions per session, never to add. Use session tags (with sts:TagSession) to drive ABAC via aws:PrincipalTag, marking tags transitive when chaining. These STS features deliver per-session least privilege from a small number of reusable roles.

Test session scoping.

Session policies passed to AssumeRole intersect with the role's permissions, shrinking but never expanding them. Session tags (needing sts:TagSession) feed ABAC through aws:PrincipalTag, and transitive tags persist across role chaining. Together they enable per-session least privilege from a few reusable roles.