# Ensure Workload Identity Federation Providers Trusting a Multi-Tenant Issuer Enforce an Attribute Condition

- Source: https://support.icompaas.com/support/solutions/articles/a_178888830647976-ensure-workload-identity-federation-providers-trusting-a-multi-tenant-issuer-enforce-an-attribute-condition
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [GCP Benchmarks](https://support.icompaas.com/support/solutions/62000112667) › [GCP Knowledge Bases](https://support.icompaas.com/support/solutions/folders/62000169178)
- Last updated: 2026-09-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that any Workload Identity Federation pool provider configured to trust an identity provider (IdP) that uses a single issuer URL across multiple tenants (such as GitHub Actions or Terraform Cloud) has an attribute condition configured to restrict which external identities can successfully authenticate, rather than relying on the issuer URL alone.

**Rationale**

Some external identity providers, such as GitHub Actions and Terraform Cloud, issue tokens using the same issuer URL for every customer or organization using that platform, meaning that trusting the issuer alone would allow any tenant of that IdP, not just the organization's own repositories or workspaces, to potentially exchange tokens for Google Cloud credentials. Configuring an attribute condition (for example, restricting the assertion's repository or organization claim to the organization's own values) closes this gap and ensures that only the organization's own workloads can federate, preventing what is commonly referred to as the confused deputy problem.

**Impact**

-   Prevents unrelated tenants of a shared-issuer identity provider from federating into the organization's Google Cloud environment
    
-   Closes the confused deputy risk inherent to multi-tenant OIDC issuers
    
-   Requires careful condition syntax (CEL) to avoid inadvertently blocking legitimate workloads
    

**Default Value**

Workload Identity Federation providers do not require an attribute condition by default; without one, any token from the trusted issuer that otherwise matches the audience and mapping can be exchanged, regardless of which tenant issued it.

**Pre-Requisites**

-   An existing Workload Identity Pool and provider configured to trust a multi-tenant IdP
    
-   Knowledge of the specific claim values (e.g., repository, organization, workspace) that uniquely identify the organization's legitimate workloads
    
-   IAM permissions to edit Workload Identity Pool providers (e.g., Workload Identity Pool Admin)
    

**Test Plan**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to IAM & Admin > Workload Identity Federation.
    
4.  Select the pool and provider configured for the multi-tenant IdP (for example, GitHub or Terraform Cloud).
    
5.  Open the provider's configuration and review the Attribute Condition field.
    
6.  Verify that an attribute condition is present and correctly scopes access to the organization's own tenant, repositories, or workspaces.
    
7.  If no attribute condition is configured, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to IAM & Admin > Workload Identity Federation and select the relevant pool and provider.
    
4.  Select Edit provider.
    
5.  In the Attribute Condition field, enter a CEL expression that restricts authentication to the organization's own tenant (for example, restricting assertion.repository\_owner for GitHub, or the equivalent organization/workspace claim for other providers).
    
6.  Select Save and refetch token (if available) to validate the mapping and condition.
    
7.  Save the provider configuration and test authentication from an approved workload to confirm it still succeeds, and from an unrelated tenant if feasible to confirm it is now rejected.
    

**Backout Plan**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to IAM & Admin > Workload Identity Federation and select the relevant pool and provider.
    
4.  Select Edit provider.
    
5.  Remove the Attribute Condition expression.
    
6.  Save the change.
    

**Reference**

-   [https://cloud.google.com/iam/docs/workload-identity-federation](https://cloud.google.com/iam/docs/workload-identity-federation)
    
-   [https://cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation](https://cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.