GCP_CAN_FEDERATE_IDENTITY
Summary
FSProtect ACL Alias
GCP_CAN_FEDERATE_IDENTITY
GCP Alias
Persistence & Impersonation
Affected Object Types
Service Accounts
Exploitation Certainty
Certain
Granting Roles
roles/iam.workloadIdentityUser
Description
GCP_CAN_FEDERATE_IDENTITY indicates that an external identity (e.g., an AWS IAM role, GitHub Actions workflow, or Azure AD managed identity) has been granted roles/iam.workloadIdentityUser on a GCP Service Account via a Workload Identity Federation (WIF) pool. This allows the external identity to exchange its native credential for a short-lived GCP access token that impersonates the target SA.
This edge represents an existing WIF bridge that can be walked across — an attacker who controls the external identity (e.g., compromises the AWS account, GitHub repository, or Azure tenant) can immediately impersonate the bound GCP service account without any GCP credentials.
Key abuse scenarios:
Compromise the bound AWS role → exchange AWS STS credentials for GCP SA token.
Exploit a GitHub Actions workflow in a repository bound to a WIF pool → run code that authenticates as the GCP SA.
Supply-chain attack on a CI/CD pipeline with WIF binding → steal GCP access on every build.
Identification
gcloud CLI
GCP Console
Open GCP Console → IAM & Admin → Workload Identity Federation.
For each pool, review the provider configuration (trusted issuer/account).
Open each SA → Permissions → check for
Workload Identity Userbindings containing pool subjects.
Exploitation
The exploitation path depends on which external identity provider is trusted by the WIF pool binding. In all cases the attacker must first control or compromise the trusted external identity, then perform the STS token exchange below.
GitHub OIDC-backed pool
AWS-backed pool
Compound path: Compromise external identity trusted by WIF pool → exchange for GCP SA token → access all resources the SA can reach (Secret Manager, GCS, IAM) → impersonate further SAs via generateAccessToken.
Persistence: The WIF binding is permanent. Re-compromising any identity trusted by the same pool immediately restores GCP access without requiring IAM changes.
Mitigation
Audit all WIF bindings on service accounts, especially privileged ones.
Use narrow attribute conditions to restrict which external subjects can federate:
Scope WIF bindings to specific subjects rather than entire pools (
principalSet://.../*is too broad).Monitor external identity providers for compromise — if a GitHub repo or AWS account is compromised, all bound GCP SAs are at risk.
Regularly review and rotate WIF pool configurations.
Detection
Data Access
GenerateAccessToken (via WIF)
protoPayload.authenticationInfo.serviceAccountDelegationInfo
Alert on:
Token exchanges from unexpected external subjects.
WIF authentications from repositories or accounts not in an approved allowlist.
Token generation for privileged SAs via WIF.
References
https://cloud.google.com/iam/docs/workload-identity-federation
https://cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation
https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform
Last updated
Was this helpful?