GCP service accounts with downloadable user-managed keys

What makes a user-managed key risky

Service accounts have two kinds of key pairs: Google-managed, which Google rotates and never hands out, and user-managed, where you download the private key. Google’s key management best practices put it bluntly: having the private key is similar to knowing a user’s password, and the main threats are credential leakage and privilege escalation.

The file is portable and quiet. It works from any machine, it does not go through your SSO or MFA, and it ends up in places nobody tracks: laptops, CI variables, container images, source control. Google’s key creation page adds that a service account can have up to 10 keys and that by default keys never expire.

Finding user-managed keys

for sa in $(gcloud iam service-accounts list --format="value(email)"); do
  echo "== $sa"
  gcloud iam service-accounts keys list --iam-account="$sa" --managed-by=user
done

The CREATED_AT and EXPIRES_AT columns show when each key was made and whether it has an expiry.

When the rule fires

ZopNight checks two things for each identity it inventories: the principal is a service account, and ZopNight has recorded that the account has at least one user-managed key. Both must hold. The key’s age is not considered here; age is the job of GCP Service Account Key Not Rotated Within 90 Days. One finding is raised per service account, not per key.

Accounts that produce no finding

Service accounts with only Google-managed keys are silent, and so are users and groups. If ZopNight has no confirmed record of user-managed keys for an account, it does not assume they exist.

Credential risk, no saving

This finding carries a $0 saving. The risk is a leaked key giving an outsider the account’s permissions until someone notices and deletes it, and Google notes a leaked key might take bad actors days or weeks to discover, so you rarely know the moment it happened.

Removing the need for key files

1. Find where each key is used. Google’s service account insights and the Key Authentication Events metric show whether and when each key was last used.
2. On GKE, use Workload Identity Federation for GKE and bind the Kubernetes service account.
3. On Cloud Run, Compute Engine and other Google Cloud runtimes, attach the service account to the resource so it gets short-lived credentials automatically.
4. Outside Google Cloud, configure Workload Identity Federation with your identity provider.
5. Disable the key first, watch for failures, then delete it: gcloud iam service-accounts keys disable KEY_ID --iam-account=SA_EMAIL, followed by gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_EMAIL.
6. Enforce iam.disableServiceAccountKeyCreation so new keys cannot be created.