What identity does a Cloud Run service run as?

If you don't specify one, it runs as the default Compute Engine service account, which typically holds Editor on the whole project. That's far more than a single service needs, so a compromise inherits project-wide write access. Deploy with a dedicated --service-account scoped to the roles the service actually uses.

Why not use the default service account for Cloud Run?

Because it's broadly privileged (often Editor) and shared across workloads, so it violates least privilege and widens the blast radius of any compromise. A per-service account with only the roles that service needs keeps a breach contained to that service's permissions.

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.

see_it · fix_it

The misconfig, then the fix

Each verdict below is the actual Cloud Run Config Auditor run on the snippet, not a description of one.

before

gcloud run deploy api \
  --image=gcr.io/my-project/api \
  --region=us-central1 \
  --service-account=123456-compute@developer.gserviceaccount.com

Fails · auditor verdictRuns as the default Compute Engine service account, which is broadly privileged (often Editor on the whole project). If this service is compromised the blast radius is the entire project. Create a dedicated service account with only the roles this service needs and deploy with it.

after

gcloud run deploy api \
  --image=gcr.io/my-project/api \
  --region=us-central1 \
  --service-account=api-runner@my-project.iam.gserviceaccount.com

Passes · auditor verdictRuns as a dedicated service account (api-runner@my-project.iam.gserviceaccount.com), so its IAM permissions can be scoped to exactly what this service needs.

fix · --service-account=my-service@PROJECT_ID.iam.gserviceaccount.com

why_it_matters

Every Cloud Run service runs as some identity, and if you don't set one, it's the default Compute Engine service account. That account is granted Editor on the project by default, so the service can read and write across almost every resource, far beyond what one service needs. If the service is compromised, through a dependency, an injection, or a bug, the blast radius is everything Editor can touch.

Create a dedicated service account per service with only the roles it needs, and deploy with --service-account. The service's permissions then match its job, and a compromise is bounded to those roles. The auditor fails a deploy that runs as the default Compute account and passes one that names a dedicated service account.

…-compute@developer…often Editor on the whole projecta dedicated, scoped service account

more_misconfigs

Related GCP misconfigurations

IAM & access

roles/editor as the default grant

Read it Cloud Run config

No max-instances, so cost is unbounded

Read it

See all 7 misconfigurations.

faq

Questions & answers

What identity does a Cloud Run service run as?: If you don't specify one, it runs as the default Compute Engine service account, which typically holds Editor on the whole project. That's far more than a single service needs, so a compromise inherits project-wide write access. Deploy with a dedicated --service-account scoped to the roles the service actually uses.
Why not use the default service account for Cloud Run?: Because it's broadly privileged (often Editor) and shared across workloads, so it violates least privilege and widens the blast radius of any compromise. A per-service account with only the roles that service needs keeps a breach contained to that service's permissions.

Fixing one binding is easy. Getting the whole project to least privilege is the work.

I review which principals hold primitive and escalation roles, how your workloads are scoped, secrets handling, and the Cloud Run defaults that widen the blast radius. Book a call, or leave your email.

Book a call

Prefer proof first? See how this plays out in real case studies →