An automation system currently uses long-lived JSON service account keys stored in a vault for API access to networking operations. What is the recommended secure alternative to eliminate reliance on those keys?

The correct answer is to replace long-lived keys with Workload Identity or workload identity federation. Long-lived service account keys pose a significant security risk because if compromised, they grant persistent access. Workload Identity allows applications running on Google Kubernetes Engine (GKE) to impersonate service accounts, obtaining short-lived credentials directly from the metadata server. Workload identity federation extends this concept to workloads outside of Google Cloud, enabling them to authenticate as Google Cloud service accounts without needing static keys. Both methods provide ephemeral, automatically rotated credentials, drastically reducing the attack surface. Requiring monthly manual rotation is an operational burden and still leaves a window of vulnerability between rotations. Enabling OS Login for the service account is irrelevant as OS Login manages SSH access to VMs, not API access for service accounts. Storing keys in Secret Manager is better than a generic vault but still relies on long-lived keys, and disabling logging of vault access is a security anti-pattern that hinders auditing and incident response.