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