FDE Times: AWS cross-account roles — ExternalId stops the confused deputy, not a password
A 6 November FDE Times guide for FDEs stuck on AccessDenied after a customer sends a role ARN: check trust Principal, case-sensitive role name, Conditions, your sts:AssumeRole policy, Organizations SCPs, then role-chaining’s one-hour cap—and treat ExternalId as per-customer confused-deputy protection.
FDE Times covers the morning many AWS-side FDEs know: the customer says the cross-account role is ready, the first assume-role returns AccessDenied, and kickoff is in twenty minutes. Assume-role needs two doors open—the customer trust policy and sts:AssumeRole on your identity—and the error rarely says which one failed.
ExternalId exists to stop the confused deputy: if customer B pastes customer A’s role ARN into your product, B’s ExternalId must not unlock A’s data. The vendor generates one ExternalId per customer, puts it in the trust Condition, and sends it on every call. Anyone who can view the role can often read the ExternalId, so it is not a secret password—control of the value matters more than hiding it.
The debugging order runs Principal → ARN/role-name case → Conditions (ExternalId, MFA, source IP) → your own AssumeRole permission → Organizations SCPs that can block STS even when both IAM policies look right → role chaining’s one-hour session limit. Onboarding should also try assume-role without ExternalId and refuse to store a loose trust policy. Asking for admin “to save time” costs more trust than a scoped read-only role ever will.
Source: fdetimes.net