Auditing Service Account Key Lifecycle

Auditing service-account key lifecycle: a downloaded key is a password for a robot with real power

A service account is a non-human identity a workload uses to call cloud and platform APIs, and its key is a long-lived credential with no user, no second factor, and often broad platform privilege behind it. That makes a downloaded service-account key one of the most dangerous credentials in a system: it is a bearer secret that grants a workload's full authority to anyone who copies the file, and workloads have real power. The lifecycle failures are specific. A user-managed key file that never expires gets copied into repositories, CI configuration, and developer laptops and lingers there for years. A service account granted more privilege than its workload needs makes the key a broad credential rather than a narrow one, so a leak grants the excess. A key that is never rotated, with no owner tracking who holds copies, cannot be reasoned about or safely retired. A service account whose key can be created or downloaded by someone who should only be allowed to use the account lets a lesser principal export standing credentials. And a service account that was disabled or deleted but whose outstanding keys still authenticate leaves live access after the account was supposedly gone. The audit prefers keyless workload identity, and where keys exist, checks they are minimally privileged, rotated, owned, non-exportable by lesser principals, and truly dead when the account is. You audit this by finding every key, what it can do, who can export it, and whether it can be killed.

When to use

• A cloud or platform service account authenticates a workload with a long-lived key or credential file.
• A service account may be over-privileged, its key may never expire or rotate, or the key may be exportable by a principal who should only use the account.
• Keys may be copied into repos, CI, or laptops, or outstanding keys may survive the account being disabled.

Scope check

Test service-account key lifecycle only against accounts and projects you own or are authorized to assess, with test service accounts. Creating, downloading, using, and deleting keys changes real access and identity state, so use test accounts and never export, use, or delete a service-account key that is not yours. If you can't name the authorization, stop.

The loop

1. Establish each service account's intended privilege and key posture first. For every service account, name the minimal privilege its workload needs, whether it should use a key at all or a keyless workload identity, how any key is meant to rotate, and who may create or download it. This is the false-positive killer: a workload using keyless identity, or a service account with least-privilege roles whose key is rotated, owned, non-exportable by lesser principals, and truly revoked on disable, is behaving correctly. Name the intended posture, then test each account.

2. Prefer keyless and inventory the keys that exist. Determine which workloads could use a keyless workload identity but instead use a downloaded key. Inventory every user-managed key: where it lives, when it was created, and whether it has ever been rotated. A downloaded long-lived key where keyless identity was possible is avoidable standing exposure.

3. Test privilege against workload need. Compare each service account's granted roles against what its workload actually calls. Exercise the key against APIs and resources outside the workload's function and confirm they are refused. A service account with project-wide or broadly privileged roles for a narrow workload makes its key a broad credential, so confirm least privilege.

4. Test rotation, ownership, and exposure. Check whether each key has a bounded lifetime and a rotation process, and an owner who tracks who holds copies. Search repositories, CI configuration, and images for copied key files. A key that never rotates, has no owner, or sits in a repo is a credential nobody can safely retire or account for.

5. Test who can export a key and whether disable revokes. Check which principals can create or download a key for each service account, and confirm a principal who should only use the account cannot export its credentials. Then disable and delete a service account and confirm its outstanding keys stop authenticating. A lesser principal who can export a key gains standing credentials, and a key that outlives the account's deletion is live access to a ghost.

6. Confirm and record. Confirm with test accounts by using an over-privileged key beyond its workload, exporting a key as a principal who should not, finding an unrotated key in a repo, or authenticating with a key after the account was disabled, without touching real accounts. Kill the lead if workloads use keyless identity or least-privilege rotated owned keys, only authorized principals can export them, and disabling the account revokes them. Record the over-privileged, unrotated, or exportable key, the workload-level access it grants, and the excess privilege, missing rotation, or exportable key material.

Where service-account key lifecycle leaks

• Downloaded keys where keyless was possible. A user-managed key file for a workload that could use keyless identity is avoidable long-lived exposure that ends up in repos and laptops.
• Over-privileged service accounts. Roles broader than the workload needs make the key a broad credential, so a leak grants the excess privilege, not just the one function.
• No rotation or ownership. A key that never rotates and has no owner tracking its copies cannot be reasoned about or safely retired.
• Exportable by a lesser principal. A principal who should only use the account but can create or download its key gains standing exportable credentials.
• Keys that survive account disable. Outstanding keys that still authenticate after the service account is disabled or deleted leave live access to an account that should be gone.

Worked example (a confirm and a kill)

Confirm. A workload authenticates with a downloaded user-managed service-account key; the account holds a broad project-editor role, the key has never rotated since creation, and a copy sits in a CI configuration file in a repository. On a test project, the key from the repo performs project-wide writes far outside the workload's function and continues to work long after creation with no rotation, and a developer with only use-the-account permission is able to download a fresh key. Confirmed over-privileged, unrotated, exportable, and exposed service-account key, high, remediation = move the workload to a keyless workload identity, scope the account to least privilege, rotate and remove the exposed key, and restrict key creation to authorized principals only.

Kill. The workload uses a keyless workload identity, or where a key exists the service account holds only least-privilege roles, the key rotates on a bounded schedule with a named owner, no copy appears in any repo or CI config, only authorized admins can create or download a key, and disabling the account immediately stops its keys from authenticating. An out-of-scope call is refused, a lesser principal cannot export a key, and a disabled account's key is dead. Killed, kill_reason = "workloads use keyless or least-privilege rotated owned keys, only authorized principals can export them, and disable revokes them; no key grants workload access past its intended bounds."

Rationalizations to reject

• "The workload needs a key." → Many workloads can use a keyless workload identity instead; prefer it, and where a key is unavoidable, scope, rotate, and contain it.
• "It is only a service account." → A service account often has broad platform privilege and no second factor; its key is a high-value bearer credential, not a low-stakes one.
• "The key is in our private repo." → A key in any repo, private or not, is copied, cloned, and cached beyond your control; keep key material out of repos and rotate any that lands there.
• "We grant editor to keep it simple." → Broad roles make the key a broad credential; scope the account to the exact APIs the workload calls so a leak is bounded.
• "We deleted the service account." → Confirm its outstanding keys actually stopped authenticating; a key that outlives the account is live access to an identity you think is gone.

Executing this in practice

You need the inventory of service accounts and their keys, each account's granted roles versus its workload's calls, each key's rotation and ownership, which principals can export a key, and whether disabling an account revokes its keys. With test accounts, exercise a key beyond its scope, export one as a lesser principal, search repos and CI for copies, and authenticate after disabling the account. Reading the account's roles and key settings shows the intended posture; a key that works out of scope, exports to the wrong principal, or survives disable shows where it fails.

Related

• auditing-api-key-and-token-lifecycle - the general key-lifecycle skill; a service-account key is a specific long-lived credential with the same scope, expiry, and revocation questions.
• hunting-non-human-identity-and-secret-reachability - where a service-account key can be reached and reused; that skill hunts the exposure this one bounds.
• mapping-service-account-impersonation-chains - once a key is held, impersonation chains extend its reach; that skill maps where the account's authority leads.
• hunting-iam-privilege-escalation-paths - an over-privileged service account is an escalation edge; that skill traces the path its excess privilege opens.
• FINDING-SCHEMA.md - source = the over-privileged, unrotated, or exportable service-account key, sink = the workload-level access it grants, evidence = the excess privilege, missing rotation, or exportable key material.