How to rotate Google Cloud service account keys

Create a second key for the same service account, replace the JSON key file everywhere it's used, disable the old key and watch your applications, then delete it once they're fine. A service account can hold up to 10 keys, so the old and the new key overlap for as long as you need (Google Cloud docs). Google's own rotation process has the same five steps: find the keys, create new ones, replace them in every application, disable the old ones and monitor, then delete (key rotation). One catch: deleting a key doesn't revoke short-lived credentials already issued from it.

Crunu doesn't create, disable or delete Google Cloud keys; it has no Google Cloud integration. It tells you which key files a departing person could read, stores the new file as a new version of the environment, and puts it on the machines that need it.

Check three things before you start

Key creation may be blocked. The iam.disableServiceAccountKeyCreation organization policy is enforced by default for organizations created on or after May 3, 2024. If creating a key fails, an administrator has to exempt the project with a tag and a conditional rule, and Google asks to exempt only projects that truly need keys.

A key file is a long-lived secret. By default, service account keys never expire. An organization policy can limit how long they stay valid, but Google doesn't recommend expiring keys as a rotation method, because they cause outages when nobody replaces them in time. Google recommends rotating at least every 90 days, and at once if a key may be compromised.

There may be a way out. For workloads outside Google Cloud, Google recommends Workload Identity Federation instead of keys, and the documentation on Application Default Credentials warns that service account keys create a security risk (ADC docs). If a reissue is due anyway, it is the cheapest moment to move a workload off keys.

Reissue without downtime

gcloud iam service-accounts keys create etl-worker-key.json \
  --iam-account=etl-worker@kiteline-data.iam.gserviceaccount.com
crunu pull --env data-pipeline/production
gcloud iam service-accounts keys delete OLD_KEY_ID \
  --iam-account=etl-worker@kiteline-data.iam.gserviceaccount.com

crunu pull keeps the previous file next to the new one with a .prev suffix, so the old key also stays on that disk until the next pull. Disabling it in Google Cloud is what makes that copy harmless.

Why deletion isn't the end

Most providers treat a deleted key as a closed door. Google Cloud adds a delay you can't shorten from the key itself: a key can be used to obtain short-lived credentials, and deleting the key doesn't revoke the ones already issued. They keep working until they expire. If you suspect misuse, deleting the key isn't enough: Google says revoking those credentials requires disabling or deleting the service account. That's why this page marks revocation as delayed.

When to reissue a key

• A departure. A key authenticates as the service account, not as the person who downloaded it, so removing that person from your project changes nothing for the key. Reissue every key file they could read. In Crunu, removing the person produces a reissue checklist naming those files by path.
• A leak. Delete the key immediately, and if it could have been used, disable the service account until you've reviewed what it did. Then create a new key or, better, a new setup without keys.
• Every 90 days. To find keys older than a given date, Google suggests searching Cloud Asset Inventory for service account keys by creation time.

What to rotate when a developer leaves covers the full order of work, and the offboarding checklist lists what to reissue in your stack. Google Cloud remains the place where keys are created, disabled and deleted.