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

The goal is to grant a Compute Engine VM read‑only access to a single Cloud Storage bucket while adhering to least‑privilege principles. Two documented approaches are available: (1) create a service account, download its JSON key file, and attach the key to the VM; (2) configure Workload Identity Federation so the VM obtains short‑lived OAuth tokens from an external identity provider without storing any long‑lived secret.

The key‑file method is simple to set up but introduces a long‑lived credential that must be rotated manually, raising the risk of stale keys if rotation lapses. The federation method issues tokens that expire after a short period and are bound to the workload identity, yet the exact inactivity window and revocation propagation delay for OAuth refresh tokens and impersonation tokens are not uniformly documented across Google APIs, leaving operators uncertain how quickly access is cut off after a credential is revoked.

Which approach better satisfies the requirement to avoid storing long‑lived secrets while ensuring timely revocation of access? What is the maximum acceptable delay for revocation propagation when using workload identity federation? How does the absence of built‑in expiry for service account keys affect operational overhead compared with federation?