GCP service account keys: why to avoid them and what to use

A Google Cloud service account key is a long-lived credential with no second factor, so a leaked key gives immediate access. Google recommends avoiding user-managed keys. Use an attached service account or Workload Identity Federation instead, and disable key creation by organization policy.

Why keys are a problem

Google lists the main risks in its guidance on managing service account keys:

• Leakage. Keys end up in source repositories, public buckets, email and backups.
• Privilege escalation when keys are poorly protected.
• Loss of attribution. If many people share one key, audit logs cannot tell them apart.
• No second step. There is no MFA on a key file.

A key is a file. Files get copied, committed and forgotten, and nothing expires them unless you set it up.

What to use instead

Google's guidance names several approaches that avoid a key file entirely:

1. Attached service accounts. A workload running on Google Cloud, such as a VM or a managed service, runs as a service account and gets credentials from the platform.
2. Workload Identity Federation. A workload outside Google Cloud, such as a CI system, exchanges its own identity token for short-lived Google credentials.
3. Your own credentials in development. Developers can use their own account locally rather than a shared key.
4. The signJwt API for domain-wide delegation, in place of a key.

Google also notes that IAM Conditions and VPC Service Controls can limit what a compromised service account can reach.

Block key creation by policy

Guidance is not enough, because people under deadline pressure create keys. Google recommends applying the constraints that disable service account key creation and key upload at the organization root. Override them only for projects that truly cannot use a secure alternative.

There is also a service account key exposure response constraint. Set to DISABLE_KEY, it makes Google Cloud automatically disable keys it detects as leaked. Changing these constraints needs the orgpolicy.policy.set permission, which the Owner and Editor roles do not include.

If you must use a key

Sometimes a legacy tool leaves no choice. Google's advice for that case:

• Keep keys out of code and binaries. If one is committed, delete it in IAM right away.
• Avoid storing keys as plain files. A hardware module, TPM or software key store is better.
• Use one service account per application and one key per machine, to keep audit trails useful.
• Rotate keys, and disable or delete unused ones.
• Use expiry times for temporary non-production needs, not production.
• Check that an externally sourced credential file has the type service_account before using it.

Finding what you already have

Start with an inventory of user-managed keys per project, their age and last use. Delete the ones nobody can explain. Then turn on the organization policy so the number cannot grow, and track the shrinking count as a simple metric.

Quick check

Sources

• Best practices for managing service account keys

Last reviewed: 19 October 2026.