Workload Identity Attribute Mapping Policy Configuration

What Workload Identity Federation Attribute Mapping and Conditions Are

Workload Identity Federation allows external workloads (such as third-party CI/CD runners, Kubernetes clusters, or multi-cloud services) to authenticate to Google Cloud by exchanging external OIDC or SAML assertions for short-lived Google Cloud federated tokens. Attribute mappings define how incoming token claims (assertion.CLAIM_NAME) map to standard Google attributes (google.subject) and custom attributes (attribute.CUSTOM_NAME). Attribute conditions use Common Expression Language (CEL) expressions evaluated by Google Cloud's Security Token Service (STS) to validate and filter assertions before issuing any federated credentials.

How It Meets the Requirements

• Provider-level token filtering: Setting --attribute-condition="assertion.repository_owner == 'example-org' && assertion.environment == 'production'" ensures that the Workload Identity Pool Provider evaluates the incoming OIDC token assertions upon receipt. If the workload is not from example-org or is not deploying to production, STS immediately rejects the exchange request and refuses to issue a token.
• Translating external tokens into Google credentials: The --attribute-mapping flag maps google.subject=assertion.sub (ensuring unique principal identity tracking under 127 bytes) and creates custom attributes attribute.owner and attribute.env from assertion.repository_owner and assertion.environment respectively.
• Granular IAM access via principal sets: Granting the role directly to principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.env/production ensures that any authenticated identity carrying the mapped attribute.env value of production from that pool receives the necessary IAM permissions without managing long-lived keys.

Key Advantages and Capabilities

• Elimination of secret management: Eliminates the lifecycle overhead and leakage risk of user-managed service account keys.
• Fail-closed perimeter security: Provider-level attribute conditions stop unauthorized tokens at the STS boundary before they ever touch IAM or resource APIs.
• Contextual and granular IAM bindings: Allows security teams to bind IAM roles to specific principal sets based on custom mapped attributes like branch, repository, or environment.
• Auditability: Mapped google.subject attributes appear directly in Cloud Audit Logs to provide traceability for every external workload action.

Why This Is Optimal

Evaluating attribute conditions at the provider level minimizes security exposure and computational overhead by rejecting untrusted pipelines immediately. Leveraging mapped custom attributes in IAM principal sets ensures a least-privilege access model without creating individual service accounts or keys for each repository.