Temporary sessions: preserve caller lineage through role chains

Last updated: 5 Oct 20266 min read

tutorial

A role session carries an assumed-role identity, expiry, and optional source identity or session tags. A second AssumeRole call forms a role chain with its own duration limit; only tags marked transitive continue into later sessions. Session names supplied by callers are useful labels but are not necessarily a trusted person identifier. Authorization and audit should depend on controlled issuer attributes and recorded source identity where the integration supports them.

Operational decision

A release controller enters a tools account, then assumes a production deploy role. Require the first issuer to provide a reviewed change identifier and source identity, and permit only the intended second role. Keep the second session shorter than the expected deployment plus rollback window, or arrange safe credential refresh before expiry; a long-running migration cannot rely on one credential indefinitely. Verify that the project session tag survives the chain only when it is intentionally marked transitive, and deny callers that try to set a different project value. Record both role assumption events, source identity, session ARN, change identifier, and deployment artifact digest. Run a negative test with a missing tag and one with a forged value. Expire a disposable session mid-operation to verify the controller stops safely and can resume without double-applying a change. Do not place personal data, access tokens, or secrets in session names or tags; these fields can appear in audit records. If a workload federation path bypasses the first role, test that path separately instead of assuming the same lineage contract applies.

Release session chain
Issuer: trusted automation identity
First role: tools account, source identity retained
Second role: production deploy, explicit trust and short lifetime
Transitive tag: approved project only
Evidence: assumption events, change ID, artifact digest
Expiry test: migration resumes without duplicate effect

Cost and verification

A two-hop chain adds credential-exchange latency and more failure points, while short sessions require renewal for long tasks. Auditing S sessions costs O(S) event records plus joins across assumption events; a stable source identity lowers investigation time. Measure sessions lacking trusted lineage, failed refreshes, expired-operation count, and role assumptions outside the expected path. Credential expiry is a recovery case, not merely a security setting.

Common Mistakes

Do not use a caller-chosen session name as verified human identity.
Do not assume ordinary role tags propagate through a chain.
Do not give a migration a longer time budget than its credentials without renewal or resume logic.

Connected lessons

Practice and check

devops

cloud-security