Enforce Workload Identity Federation for VCS CI/CD Connections to GCP
Specification & Description
Mandate the use of Workload Identity Federation (OIDC) for all CI/CD pipeline connections from GitHub Actions, GitLab CI, or external version control systems to Google Cloud Platform, eliminating long-lived service account JSON keys from VCS secret stores entirely.
Technical Specifications
CI/CD pipelines deploying infrastructure or accessing Google Cloud resources must authenticate via direct Workload Identity Federation rather than static Service Account JSON keys. In this architecture, GitHub Actions or GitLab CI issues an OpenID Connect (OIDC) JWT token signed by the provider's private key. Google Cloud Security Token Service (STS) validates the token against the configured Workload Identity Pool and Provider, evaluating attribute mappings (e.g., google.subject=assertion.sub, attribute.repository=assertion.repository) and mandatory attribute conditions (e.g., assertion.repository_owner == 'MY-ORG'). Permissions can be bound directly to the federated principalSet (direct federation) or by impersonating a target Service Account with the roles/iam.workloadIdentityUser role. To ensure organization-wide compliance, the Organization Policy constraint constraints/iam.disableServiceAccountKeyCreation must be enforced at the organization or folder level, preventing engineers from generating long-lived private keys.
Security Rationale
Long-lived Service Account JSON keys stored as repository secrets represent one of the most severe attack vectors in cloud security. They have no built-in expiration, are susceptible to accidental commit leaks, log aggregation exfiltration, and untrusted CI dependency theft, and often remain active long after projects are decommissioned. In contrast, Workload Identity Federation tokens are ephemeral (valid for up to 1 hour by default), generated dynamically per workflow run, never stored at rest in repository secrets, and cryptographically tied to the exact repository, branch, or environment. A leaked token expires within minutes, preventing persistent unauthorized access.
Policy Exceptions (1)
Legacy third-party SaaS integrations that do not support OIDC web identity token exchange may use a service account key under an approved security exception. The key must be restricted with IAM Conditions and monitored in Cloud Audit Logs.
Operational & Implementation Notes
The attribute_condition is the primary security boundary in Workload Identity Federation. Without an attribute_condition (e.g., assertion.repository_owner == 'MY-ORG'), ANY GitHub user who obtains your provider name can exchange a token and assume permissions. Direct Workload Identity Federation (using principalSet directly on resources) eliminates service accounts entirely for supported services. For services requiring a service account, bind roles/iam.workloadIdentityUser to the exact repository principalSet.