Day 4 - STS and Temporary Credentials: AssumeRole, Federation, Role Chaining, Confused Deputy Prevention

AssumeRole: The Two Axes of Trust Policy and Permission Policy

A role has two policies. This distinction is the most confusing point in IAM.

• Trust policy: "Who may assume this role" (the parties allowed sts:AssumeRole). Contains a Principal = resource-based policy.
• Permission policy: "Once this role is assumed, what can be done." Identity-based policy.

For a cross-account AssumeRole to succeed, both sides must line up.

1. The target role's trust policy allows the calling account/principal as Principal
2. The caller's identity policy contains an sts:AssumeRole Allow (specifying the target role ARN)

⚠️ Pitfall: Writing "arn:aws:iam::111122223333:root" in the trust policy's Principal means "the entire account 111122223333 may assume the role," not just the root user. However, in practice only principals within that account who have been granted sts:AssumeRole can actually assume it (condition 2). The intuition that "using root as Principal is dangerous" is only half right — account-level delegation is a normal pattern, but permission control inside that account is entrusted to that account.

Federation: Turning External Identities into AWS Credentials

Federation means accessing AWS with a corporate directory (AD) or social/OIDC identity without creating IAM users.

SAML 2.0 Federation (Corporate Workforce)

[ SAML federation flow ]

  User → signs in to corporate IdP (AD FS/Okta)
       → IdP issues SAML assertion (containing role ARN)
       → AWS STS AssumeRoleWithSAML
       → Temporary credentials issued
       → Access AWS resources

The recommended approach today is IAM Identity Center (formerly AWS SSO). In multi-account environments, you define permission sets, integrate with an external IdP (Okta, Entra ID, etc.), and after a single sign-in users access multiple accounts and roles with temporary credentials. It eliminates the anti-pattern of creating IAM users in every account.

OIDC / Web Identity Federation (Apps and CI/CD)

Mobile apps (Cognito), GitHub Actions, Kubernetes (EKS IRSA), and the like use OIDC with AssumeRoleWithWebIdentity. GitHub Actions OIDC in particular matters for both the exam and real work — instead of putting long-term access keys into GitHub secrets, you assume a role with GitHub's OIDC token, eliminating key exposure risk.

🔍 Going deeper: The trust policy for GitHub Actions OIDC uses token.actions.githubusercontent.com as the OIDC provider and, in the Condition, allows only specific repos and branches via token.actions.githubusercontent.com:sub. Leaving this sub condition loose, like repo:org/*, lets any repo in the organization assume the role — dangerous. Narrow it like repo:org/repo:ref:refs/heads/main. EKS IRSA maps roles to pods using the same OIDC principle.

Role Chaining and Its Constraints

Role chaining is assuming yet another role while already operating under an assumed role: Account A → assume Role X → use Role X to assume Role Y.

Two key constraints appear on the exam.

1. The maximum session duration when chaining is fixed at 1 hour. Even if Role X's MaxSessionDuration is 12 hours, a session obtained through chaining is capped at 1 hour.
2. Some calls, such as GetSessionToken, are restricted from a chained session.

💡 Related theory: Role chaining can blur permission traceability, so avoid it where possible. Prefer session policies or direct AssumeRole instead. That said, the cross-account pattern of "reaching a spoke account through a hub account's role" is legitimate chaining. Traceability is supplemented via the assumedRole session name in CloudTrail (set sts:RoleSessionName to something meaningful).

Confused Deputy Prevention: ExternalId and aws:SourceArn

Today's security centerpiece. A Confused Deputy attack tricks a privileged party (the deputy) into exercising its privileges on behalf of a third party.

Scenario: Cross-Account Access by a Third-Party SaaS

Suppose a monitoring SaaS (e.g., Datadog) accesses your account via AssumeRole. The SaaS assumes roles for every customer from the same SaaS account. If the trust policy only checks "allow if it's the SaaS account," a malicious user could spoof their account ID as yours and get the SaaS to access your resources.

The remedy is ExternalId — a unique secret the SaaS issued only to you, embedded in the trust policy's Condition.

The SaaS passes this ExternalId when assuming your role, and it cannot assume your role using another customer's ExternalId. Isolation between customers is guaranteed.

When an AWS Service Is the Deputy: aws:SourceArn / aws:SourceAccount

The same attack is possible when a service principal (e.g., CloudWatch, S3, SNS) uses your role or resource. Here you enforce "allow only calls triggered by this specific resource" with aws:SourceArn (or aws:SourceAccount).

🎯 Scenario: "We need to create a cross-account role granting a third-party backup vendor access to our S3." The correct pattern is: ① do not hand the vendor IAM user access keys (absolutely forbidden), ② IAM role + trust policy specifying the vendor account plus an ExternalId, ③ a permission policy limited to only the needed buckets and Actions (least privilege). Without an ExternalId, a Confused Deputy hole remains through which another customer of the same vendor could access your resources. This pattern is identical for every third-party integration — Datadog, New Relic, PagerDuty, and the rest.

⚠️ Pitfall: An ExternalId is not a "password" — it blocks the attack even if guessable. The crux is that the third party issues the ExternalId; the customer does not choose it themselves. If customers picked it arbitrarily, collisions with other customers or predictability would break the isolation. On the exam, an answer choice saying "the customer freely sets the ExternalId" is a trap.

AssumeRole Through the CLI

📚 Case study: The essence of the 2019 Capital One incident was: ① WAF (inadequate SSRF defense), ② theft of EC2's temporary credentials via IMDSv1, ③ S3 access with those credentials. Temporary credentials are themselves a safeguard, but they are neutralized if the path to steal them (SSRF → IMDS) is left open. That is why IMDSv2 enforcement + least-privilege instance roles + WAF appear on the exam as one bundle. Temporary credentials are only the "time-limited if exposed" line of defense; closing the exposure path is a separate control.

Wrapping Up — Temporary Credentials as the Security Default

Today's three takeaways. First, STS issues expiring temporary credentials (including a SessionToken), and EC2/Lambda/ECS/federation all operate on top of them — replace the anti-pattern of putting long-term keys into code or CI with OIDC and instance roles. Second, AssumeRole runs on the two axes of trust policy (who) and permission policy (what), and cross-account requires both sides to allow. Third, in cross-account delegation you must block Confused Deputy with ExternalId (third parties) and aws:SourceArn (AWS services).

Tomorrow, wrapping up Week 1, we weave the IAM, STS, and policy evaluation learned so far into integrated scenarios. Through hands-on problems like "I have the permission — why is it denied," "delegate permissions to a third party safely," and "convert long-term keys to temporary credentials," we solidify Week 1's thinking framework.