Service Account Key vs Workload Identity Federation for least‑privilege VM access to a single Cloud Storage bucket

Answer first

For a Compute Engine VM that needs read-only access to a single Cloud Storage bucket, Workload Identity Federation is the approach that avoids storing long-lived secrets. A service account key attached to the VM is a long-lived credential that must be managed manually. Federation issues short-lived OAuth access tokens bound to the workload identity, so no JSON key is stored on the VM.

Confirmed facts:

• Service account keys have no built-in expiry. They remain valid until the key resource is deleted or rotated in IAM & Admin. Revocation is immediate on deletion, but the key continues to work until that action is taken.
• VMs can authenticate to Google APIs via the metadata server using the service account attached to the instance, without a key file. A key file is only required when the workload is outside GCP or when a long-lived secret is explicitly downloaded.

Likely explanation, marked for review:

• Workload Identity Federation token lifetimes are short-lived, typically minutes. Revocation of the trust relationship, pool, provider, or the IAM binding that allows impersonation is expected to stop new token issuance within a few minutes. Observed propagation is commonly reported as 5 to 15 minutes, but this is not uniformly documented across all Google APIs and may vary with IAM policy propagation. This delay should be verified in your environment.
• There is no universal maximum acceptable revocation delay. For most operational least-privilege use cases, a window of under 15 minutes is considered acceptable. If sub-minute revocation is required, federation still provides the best guarantee because token lifetime can be kept short, but you must accept the residual window until existing tokens expire.

Operational overhead comparison

Service account key:

• Persistent secret must be stored securely on the VM or injected via secret manager.
• Manual rotation schedule, secure distribution, and audit of key usage are required.
• Stale keys remain usable indefinitely if rotation lapses, increasing blast radius.

Workload Identity Federation:

• No long-lived secret stored on the VM. Tokens are obtained via the metadata server or federation endpoint and expire automatically.
• Operational work shifts to managing the workload identity pool, provider, and IAM bindings. Revocation is performed by disabling the pool/provider or removing the IAM binding.

Minimal steps for this case

1. Create a dedicated service account for the VM, e.g., [contact removed].
2. Grant least privilege on the bucket only: roles/storage.objectViewer on the specific bucket, not project-wide.
3. Attach the service account to the VM. Do not download a JSON key.
4. If you are using Workload Identity Federation with an external identity provider, create a workload identity pool and provider, map the VM identity to the service account, and grant roles/iam.workloadIdentityUser on the service account to the pool principal. Remove any existing key files from the VM.

Missing diagnostic detail that changes the recommendation: Does the VM have outbound HTTPS egress to the federation token endpoint and the Google OAuth token endpoint? If egress is blocked, federation cannot obtain tokens and a key-based approach would be required. Confirm network egress before committing to federation.