Module 17 · Multi-Cloud Identity Federation Attack Surface

Last updated: April 29, 2026

Why this module exists. Indian enterprises in 2026 are multi-cloud. Workloads on AWS, identity in Entra ID, data lakes in GCP, kubernetes on multiple clouds. Each integration uses identity federation — and each federation is a trust boundary that attackers can pivot across. The bugs that matter are at the seams between clouds, not within them.

What identity federation is (and isn’t)

Federation: cloud A trusts identities from cloud B (or an external IdP). When a B-identity calls A’s API, A’s auth layer validates a B-issued token and maps it to an A-identity for authorization purposes.

Federation is not “shared credentials.” Each cloud still authorizes independently. The attack surface is the trust mapping.

The four common patterns

Risk 1: GitHub Actions OIDC → AWS, with loose trust

GitHub Actions can mint OIDC tokens. AWS roles can trust GitHub’s OIDC issuer. Combined: GitHub workflow calls aws sts assume-role-with-web-identity using its OIDC token, gets temporary AWS credentials. No long-lived AWS keys in CI.

Bug: the AWS role’s trust policy is the only thing limiting which GitHub workflow can assume the role. A loose policy:

{
  "Effect": "Allow",
  "Principal": {"Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com"},
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:mycompany/*"
    }
  }
}

Translation: any repo in mycompany org can assume this role. A new repo created by a junior dev with public-PR-trigger workflows can be tricked into running attacker-supplied code with this AWS role. The fix:

"token.actions.githubusercontent.com:sub": "repo:mycompany/specific-repo:ref:refs/heads/main"

Pin to specific repo + specific branch.

Risk 2: third-party SaaS as confused deputy

You install a SaaS in your AWS account that needs broad permissions (“read all S3 buckets to scan for sensitive data”). The SaaS provides a role ARN; you create a role in your account that trusts the SaaS’s account, with broad permissions.

If the SaaS is compromised: attacker uses their compromised access to assume your role. They have whatever permissions you granted. Confused deputy via legitimate trust.

Mitigation: External ID. Your role’s trust policy requires the principal to supply an External ID known only to you and the SaaS. If the SaaS is compromised but the External ID is still secret (e.g., per-customer secret, encrypted in the SaaS’s own vault), the attacker can’t assume your role.

Risk 3: cross-cloud workload identity

GCP Workload Identity Federation lets GCP workloads federate with AWS, Azure, OIDC providers. The configuration:

• External provider issues identity tokens (e.g., AWS STS).
• GCP’s Workload Identity Pool maps token attributes to GCP service-account impersonation.
• GCP service account has permissions in GCP.

Attack: if AWS is compromised and the AWS principal that’s mapped is wide (e.g., “any role in this AWS account”), the AWS attacker now has GCP permissions. Cross-cloud privilege escalation.

Same in reverse: AWS roles trusting GCP service accounts via OIDC, Azure managed identities federating to AWS, etc.

Risk 4: SAML signing-key compromise

Entra ID signs SAML responses with a tenant-private key. AWS / GCP / SaaS apps that trust Entra ID validate against Entra’s published signing key.

If the signing key is compromised (Storm-0558 / 2023): forge SAML responses for any user, sign in as them anywhere. Microsoft confirmed Storm-0558 used a stolen signing key to impersonate users across 25+ tenants.

Real-world cases

• Storm-0558 / 2023 — stolen Microsoft signing key used to forge tokens; 25+ government and enterprise tenants compromised.
• Many enterprise pentests document GitHub OIDC misconfigurations that allow unauthorized AWS role assumption.
• SaaS vendor breaches (multiple, 2024-25) where customer AWS environments were accessed via the vendor’s stored AWS role assumptions.

Defender’s checklist

• OIDC trust conditions pin to specific repo + branch + workflow. Never trust “the org” or “the issuer” alone.
• External ID on every cross-account trust to a third party.
• Least privilege on federated roles — separate roles for separate workflows; minimum permissions per role.
• Audit cross-cloud federations quarterly. Each one is a trust seam; document what each one does.
• Detection: CloudTrail AssumeRoleWithWebIdentity events with unexpected principal patterns. Same for cross-cloud assumed sessions.
• Token binding / continuous access evaluation (CAE) in Entra to revoke stolen tokens within minutes when conditional access changes.
• Vendor risk management — every SaaS that assumes roles in your account is a tier-aligned risk. Document, audit, demand SOC 2.