Service Account Impersonation Token Downscoping

What this solution is

This solution combines Workload Identity Federation with Service Account Impersonation and Token Downscoping using Credential Access Boundaries to enforce strict least-privilege access for external workloads.

How it meets the requirements

• Eliminating long-lived service account keys: Workload Identity Federation exchanges external identity credentials (such as OIDC tokens from GitHub Actions or GitLab CI) for temporary Google Cloud credentials, completely removing the need to generate or store downloadable JSON private keys.
• Securing service account impersonation: Granting roles/iam.workloadIdentityUser directly on deployer-sa to a specific principal identifier (principal://iam.googleapis.com/.../subject/PIPELINE_ID) ensures that only the authorized external CI/CD workflow can impersonate the service account.
• Restricting token scope to a specific bucket: A Credential Access Boundary downscopes the short-lived OAuth 2.0 access token at generation time. Even though deployer-sa has broad project-level permissions, the downscoped token is mathematically and logically restricted to interact only with bucket-prod-artifacts and execute only the specified storage actions.

Key advantages

• Zero credential management overhead: Eliminates the lifecycle management, exposure risks, and rotation burdens of static service account private keys.
• Fine-grained runtime containment: Downscoping prevents compromised pipeline steps or unintended scripts from accessing unauthorized buckets within the project.
• Auditable identity chain: Cloud Audit Logs capture both the federated workload principal and the impersonated service account identity in access logs.
• Dynamic permission restriction: Downscoping rules are passed during token exchange without requiring permanent modifications to the underlying IAM policy bindings of the service account.

Why this is optimal

Using roles/iam.workloadIdentityUser on the service account combined with token downscoping represents the architectural best practice for external CI/CD systems interacting with sensitive cloud resources. It decouples high-level service account grants from runtime execution privileges.