Why do service accounts with broad IAM roles increase blast radius in Google Cloud?

Why This Matters for Security Teams

In Google Cloud, a service account is not just an authentication object. It is a workload identity that can inherit broad permissions, often across projects, data stores, and automation paths. When that identity is compromised, the attacker does not need to “break in” again to do damage. They can simply act as the workload, which is why blast radius grows quickly when roles are wide and long lived. This is the same pattern seen in high-impact incidents such as the 230M AWS environment compromise and the Snowflake breach, where trusted identities and access paths became the attack surface.

The core mistake is treating service accounts like static app configuration instead of privileged identities that need the same scrutiny as human admin access. NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces least privilege and separation of duties, but many cloud estates still default to convenience. In practice, many security teams discover the real blast radius only after a service account token, key, or delegated role has already been abused for lateral movement or data exfiltration.

How It Works in Practice

Service accounts increase blast radius because Google Cloud permissioning is cumulative: a single identity may have access to storage, secrets, compute, IAM policy changes, and monitoring data across multiple scopes. If an attacker steals its credentials, they can reuse the same trust path the workload uses, which makes detection difficult. That is especially dangerous when the account can mint tokens, impersonate other principals, or access secrets stored in systems like Key Management Service or Secret Manager.

Reducing this risk starts with designing service accounts around one workload and one purpose. Current guidance suggests:

• Assign the narrowest IAM roles possible, scoped to the specific project or resource.
• Prefer short-lived credentials and workload identity federation over long-lived service account keys.
• Disable unused keys and rotate any remaining credentials aggressively.
• Separate build, runtime, and admin service accounts so one compromise does not expose the full pipeline.
• Review transitive permissions, including who can impersonate the service account.

These practices align with identity-focused research in the 2024 Non-Human Identity Security Report, which shows how often non-human IAM lags behind human IAM. They also map well to workload identity patterns described by SPIFFE, where the identity of the workload is proved cryptographically rather than through static secrets. In Google Cloud, this means using identity-aware bindings and ephemeral access instead of assuming a service account should always be able to do the same thing. A compromise of one over-permissioned account can therefore become a full path into storage, secrets, and control plane actions, which is exactly what broad roles are meant to prevent. These controls tend to break down when teams reuse the same service account across multiple applications because the identity becomes shared infrastructure rather than a bounded workload.

Common Variations and Edge Cases

Tighter service account scoping often increases operational overhead, requiring organisations to balance developer convenience against reduced blast radius. That tradeoff is real in CI/CD, batch jobs, and legacy integrations where teams have historically depended on one “shared” account to keep systems running.

There is no universal standard for every edge case, but current guidance suggests treating exceptions as temporary and explicitly risk-accepted. For example, build systems may need broader access during deployment windows, but that should be time-bound and auditable. In multi-project architectures, shared service accounts can also hide privilege creep, because permissions accumulate faster than owners review them. Google Cloud environments with multiple teams, federated admin models, or third-party automation are especially prone to this problem.

NHIMG research has repeatedly shown that insecure secret handling and over-privileged non-human identities appear together in real incidents, including the Google Firebase misconfiguration breach and the 52 NHI Breaches Analysis. The practical lesson is simple: if a service account can reach sensitive data, alter IAM, or impersonate other workloads, its compromise should be assumed to affect more than the one application it was created for.

Related resources from NHI Mgmt Group

• Why do service accounts with standing privilege increase cloud blast radius?
• Why do compromised service accounts and cloud keys increase the blast radius of a supply chain attack in Kubernetes environments?
• Why do over-privileged service accounts increase the blast radius of a notebook compromise in cloud-native environments?
• Why do generative AI credentials increase the blast radius of a leak?