Workload Identity Federation Token Lifetime Extension

What Workload Identity Federation and Token Lifetime Extension are

Workload Identity Federation allows external workloads (such as AWS EC2 instances, Azure VMs, or on-premises servers) to authenticate to Google Cloud APIs by exchanging external ambient credentials for temporary, short-lived Google Cloud access tokens. This eliminates the need to create, download, and rotate static, long-lived service account JSON keys.

How it meets the requirements

1. Eliminating long-lived credentials: Workload Identity Federation uses AWS instance profile security credentials to obtain federated tokens, completely replacing static JSON keys.
2. Configuring custom token lifetime: When generating the client credential configuration via gcloud iam workload-identity-pools create-cred-config, passing --service-account-token-lifetime-seconds 14400 configures the impersonated service account token duration to 4 hours.
3. Overcoming default lifetime limits: Google Cloud IAM limits impersonated service account access tokens to a default maximum of 1 hour (3,600 seconds). To exceed 1 hour up to the 12-hour (43,200 seconds) ceiling, the specific service account must be explicitly allowed under an Organization Policy enforcing constraints/iam.allowServiceAccountCredentialLifetimeExtension.
4. Service account impersonation: Granting roles/iam.workloadIdentityUser binds the federated AWS identity pool principal directly to the target Google service account.

Key advantages and capabilities

• Zero credential management overhead: Eliminates the operational and security risks associated with storing and rotating service account keys in third-party environments.
• Policy-governed token extensions: Enforces centralized governance by ensuring extended token durations can only be assigned to approved, audited service accounts via Organization Policy.
• Auditable access: Integrates with Cloud Audit Logs to track identity federation and impersonation calls with end-to-end principal traceability.

Why this is optimal

This approach directly satisfies the 4-hour token duration requirement using native Google Cloud IAM governance without requiring custom token-refresh daemon scripts or insecure long-lived key files.