Avoid creating GCP Service Account Keys unless a workload cannot use short-lived federation or impersonation. If a key is unavoidable, store it as a secret, restrict who can create and download it, rotate it regularly, and delete it when no longer needed. Monitor for keys in source control, build systems, and exported files.
Why GCP Service Account Keys Should Be the Exception, Not the Default
service account key create a long-lived credential that can be copied, stored, exfiltrated, and reused outside Google Cloud’s normal token flow. The safer pattern is to avoid static keys altogether and use short-lived federation or impersonation wherever possible. When a key is justified, treat it as high-value identity material, not as a convenient config file.
Google Cloud service account use is easier to govern when you design for keyless access first. That means the workload proves who it is at runtime and receives a short-lived credential, instead of relying on a downloadable private key that can survive far beyond the workload that needs it.
What Good Key Handling Looks Like in Practice
If a service account key must exist, keep it under the same controls you would apply to other sensitive secrets. Store it in a secret manager or equivalent protected vault, restrict who can create and download it, and define a clear owner for rotation and deletion. The practical goal is to make the key observable, limited, and disposable.
Key hygiene also depends on scope. A key with broad project or organization access increases the damage if it is leaked, reused, or attached to an unmanaged automation path. The narrower the service account permissions and the shorter the credential lifetime, the less useful the key becomes to an attacker or an overextended integration.
For Cloud IAM readers, the most useful anchor is a broader identity-control view of the problem: Google Cloud IAM and Service Accounts Guide covers impersonation, least privilege, and the controls around service account key creation. If you need the wider governance picture, Service Account Security Guide explains how to manage service accounts across cloud and SaaS environments.
How Keys Fail in the Real World
Most key failures are not subtle. They show up when a key is copied into source control, baked into build artifacts, left in exported files, or reused by multiple systems that nobody can fully inventory. Once that happens, the credential can outlive the original purpose and become a hidden access path.
Rotation only helps if it is tied to real discovery. A key that is still present in a repository, CI job, backup, or image layer is still exposed even after the nominal rotation date. For that reason, the detection work matters as much as the rotation schedule.
Related incident patterns are worth studying because they show how quickly a single credential can widen blast radius. Cloudflare Thanksgiving breach 2023 illustrates the danger of an unrotated credential, while Okta support system breach 2023 shows how a service account credential can become the pivot into session theft and downstream compromise.
What to Monitor Before a Key Becomes an Incident
Monitoring should focus on where keys tend to escape, not just on the cloud project that owns them. Search source control, build logs, CI/CD variables, container images, exported configuration bundles, and shared file repositories for service account key material. If your detection only looks at the cloud control plane, you will miss the most common leakage paths.
It is also useful to watch for lifecycle drift. A key that has not been used for a long time, a key whose owner is unclear, or a key tied to a workload that no longer exists should be treated as a cleanup candidate. Dormant keys are often the easiest keys to forget and the easiest ones to abuse later.
For practitioners who want a dedicated reference on the broader service-account failure modes, Guide to NHI Rotation Challenges is useful for understanding why rotation is operationally hard at scale, and Ultimate Guide to NHIs gives the larger lifecycle context for governance, visibility, and offboarding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Service account keys are secret material that can be exposed in repos, logs, and artifacts. |
| NHI-05 — Overprivileged NHI | Service account keys amplify damage when the underlying account has excess access. | |
| NHI-07 — Long-Lived Secrets | The question centers on avoiding static keys and rotating them when unavoidable. | |
| Recommendation — Scan code and build paths for leaked keys and remove exposed secrets immediately. Reduce service account permissions to the minimum needed for the workload. Prefer short-lived federation and rotate any unavoidable keys on a defined schedule. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service account keys are authenticators whose lifecycle must be managed, rotated, and revoked. |
| AC-6 — Least Privilege | Restricting who can create, download, and use keys depends on limiting privilege. | |
| SI-4 — System Monitoring | Monitoring for keys in source control and build outputs is a detection requirement. | |
| Recommendation — Manage, rotate, and revoke service account keys through controlled authenticator lifecycle processes. Limit creation and use rights for service account keys to only approved administrators and workflows. Monitor repositories, pipelines, and exported files for exposed service account keys. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service account key governance depends on controlling account creation, use, and deletion. |
| CIS-8 — Audit Log Management | Detecting key creation, download, and misuse depends on usable audit telemetry. | |
| CIS-16 — Application Software Security | Keys leaking into source control and build systems are software delivery hygiene failures. | |
| Recommendation — Inventory service accounts and remove keys that are no longer required. Retain and review audit logs for service account key creation, download, and use. Prevent service account keys from entering source control, build pipelines, and deployment artifacts. | ||
Practitioner Guidance
What to prioritise: Start by removing the need for keys in any workload that can use federation or impersonation. That one decision usually cuts the largest part of the risk because it eliminates the long-lived secret entirely.
What to verify: Before you accept a key as necessary, verify who can create it, who can download it, where it is stored, and whether any workload can be moved to a short-lived alternative. If you cannot answer those four questions cleanly, the key is already too easy to lose track of.
Decision rule: If the key can authenticate to anything production-like, treat rotation and deletion as a live security task, not a periodic housekeeping task. If it cannot be justified by a current workload, remove it rather than preserving it for convenience.
Practitioner takeaway: The best gcp service account key practice is to make keys exceptional, tightly owned, and short-lived in practice, because every static key expands the window for leakage, reuse, and undetected access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org