Skip to content

gcp_hardening

GCP misconfigurations that widen your blast radius

Most GCP incidents aren't exotic exploits. They're a binding, a primitive role, or a default that hands over more access than anyone intended. Here are the common ones, each with a real before/after fix, or audit your own IAM policy and Cloud Run config.

IAM & access

A project open to the entire internet

An IAM binding to allUsers or allAuthenticatedUsers on a non-public role hands access to anyone on the internet, or anyone with any Google account, not the people you meant to grant.

The misconfig and the fix
IAM & access

roles/owner handed out day to day

roles/owner is a primitive role with full control over every resource plus the ability to rewrite IAM, so granting it for day-to-day work bypasses least privilege entirely.

The misconfig and the fix
IAM & access

roles/editor as the default grant

roles/editor is a primitive role with write access across almost every service in the project, far more than any single workload or person needs, and it's the most common over-grant in GCP.

The misconfig and the fix
IAM & access

An IAM-admin role that can self-grant owner

Roles that can edit the IAM policy, projectIamAdmin, securityAdmin, organizationAdmin, or mint service-account keys, let the holder grant themselves any other role, so a broad grant is a direct privilege-escalation path.

The misconfig and the fix
Cloud Run config

Secrets pasted into plain env vars

A credential set as a plain Cloud Run env var is stored in plaintext on the revision and readable by anyone with run.services.get, so it leaks through the service definition rather than through an attack.

The misconfig and the fix
Cloud Run config

No max-instances, so cost is unbounded

A Cloud Run service with no max-instances can scale to the project default ceiling under a traffic flood or retry storm, and you're billed for every instance it fans out to.

The misconfig and the fix
Cloud Run config

Running as the default Compute service account

A Cloud Run service with no dedicated service account runs as the default Compute Engine service account, which is broadly privileged (often Editor on the whole project), so a compromise reaches the entire project.

The misconfig and the fix