The Two Mitigations for the Service-Account Confused Deputy in the Cloud

What it is

Kat Traxler's breakdown of the cloud service-account confused-deputy problem, splitting it by identity ownership and — more usefully than the summary conveys — separating the three distinct privilege-escalation actions on a customer-managed identity so an engineer knows which single one is actually the confused-deputy gate.

How it works

The confused deputy is a privileged intermediary tricked into acting for a caller lacking the authority itself. The page's central clarification: for customer-managed identities, three separate actions all enable privilege escalation, but only one is the confused-deputy control. On GCP:

• attach — iam.serviceAccounts.actAs: binds an identity to a resource. This is the confused-deputy gate.
• delegate — iam.serviceAccounts.setIamPolicy on the SA: grants the actAs edge in the first place.
• mint — iam.serviceAccounts.getAccessToken via roles/iam.serviceAccountTokenCreator: token issuance. Note roles/iam.serviceAccountUser does not grant this.

The attachment check is bind-time, not runtime: once attached, the workload pulls the identity's token from the metadata endpoint with no re-evaluation. None of the three gates is a standalone API — each is enforced by the service performing the attachment. Across clouds the attach gate maps to .actAs / iam:PassRole / Azure's assign/action.

For provider-managed identities, the guard lives on the provider side. AWS surfaces two customer-controllable mechanisms: FAS (Forward Access Sessions carry the original principal, and the downstream service re-checks that same principal holds the permission on the downstream resource — e.g. the KMS key — so the deputy never exceeds the caller's rights), and condition keys (aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, aws:SourceOrgPaths). GCP and Azure keep theirs opaque — Azure's fires as a LinkedAuthorizationFailed error whenever an operation references a second resource (e.g. creating something that joins a subnet demands Microsoft.Network/virtualNetworks/subnets/join/action on that subnet, not just on the resource being created).

What to do

When auditing GCP privilege-escalation risk, don't treat serviceAccountUser, serviceAccountTokenCreator, and setIamPolicy as interchangeable — they gate attach, mint, and delegate respectively, and only actAs (attach) is the confused-deputy path. On AWS resource policies reachable by service principals, set aws:SourceArn/aws:SourceAccount (or the Org variants) to constrain who the service can act on behalf of. Expect Azure's guard only as a LinkedAuthorizationFailed.