Why is roles/editor considered too broad?

Editor grants write access across almost every service in the project, so it's far more than any one workload needs. A leaked editor credential can modify or delete resources project-wide. Replace it with predefined roles scoped to the services the principal actually uses.

Do default GCP service accounts have roles/editor?

Yes. The default Compute Engine and App Engine service accounts are granted editor on the project automatically, and anything you run on a VM, function, or older Cloud Run deploy runs as them by default. Create a dedicated, scoped service account per workload and strip the broad grants off the defaults.

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.

see_it · fix_it

The misconfig, then the fix

Each verdict below is the actual GCP IAM Least-Privilege Analyzer run on the snippet, not a description of one.

before

{
  "bindings": [
    {
      "role": "roles/editor",
      "members": ["serviceAccount:ci@my-project.iam.gserviceaccount.com"]
    }
  ]
}

Fails · auditor verdictroles/editor granted to: serviceAccount:ci@my-project.iam.gserviceaccount.com. Editor is a primitive role with write access across almost every service in the project, far more than any one workload needs. Swap it for the predefined roles that cover the specific services the principal actually uses.

after

{
  "bindings": [
    {
      "role": "roles/run.developer",
      "members": ["serviceAccount:ci@my-project.iam.gserviceaccount.com"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["serviceAccount:ci@my-project.iam.gserviceaccount.com"]
    }
  ]
}

Passes · auditor verdictNo roles/editor bindings. Access is expressed with narrower predefined or custom roles. Good.

fix · Apply the change shown in the after snippet.

why_it_matters

Editor is the reflex grant: it lets the principal create, update, and delete resources across nearly every service, so whatever they're trying to do works on the first try. That convenience is the problem. A CI service account with editor can touch far more than the one service it deploys, and the default Compute and App Engine service accounts get editor automatically, so any workload running as them inherits it.

Swap editor for the predefined roles that cover the specific services the principal uses. It's more bindings, but each one is legible and scoped, and a leaked credential is bounded to the services it actually needed. The analyzer fails any editor grant to a non-public principal and points you at narrower predefined roles.

roles/editor → a CI accountwrite access to almost everythingpredefined roles per service instead

more_misconfigs

Related GCP misconfigurations

IAM & access

roles/owner handed out day to day

Read it Cloud Run config

Running as the default Compute service account

Read it

See all 7 misconfigurations.

faq

Questions & answers

Why is roles/editor considered too broad?: Editor grants write access across almost every service in the project, so it's far more than any one workload needs. A leaked editor credential can modify or delete resources project-wide. Replace it with predefined roles scoped to the services the principal actually uses.
Do default GCP service accounts have roles/editor?: Yes. The default Compute Engine and App Engine service accounts are granted editor on the project automatically, and anything you run on a VM, function, or older Cloud Run deploy runs as them by default. Create a dedicated, scoped service account per workload and strip the broad grants off the defaults.

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 →