GCP projects that grant the legacy Owner, Editor or Viewer basic roles

How broad the basic roles really are

Owner, Editor and Viewer predate IAM; Google’s docs now call them the legacy basic roles. The roles overview describes basic roles as highly permissive and warns that they include thousands of permissions across all Google Cloud services. Viewer grants read-only access across most services. Editor adds the ability to create and delete resources in most services. Owner adds managing roles and permissions for the project and setting up billing.

Two details make them worse than they look. Holders also get extra access some services give to basic-role members, such as Cloud Storage convenience values and BigQuery special groups. And unlike other roles, conditions cannot be added to bindings for the legacy basic roles, so you cannot limit them by time or resource.

Finding basic-role bindings

gcloud projects get-iam-policy PROJECT_ID \
  --flatten=bindings \
  --filter="bindings.role=roles/owner OR bindings.role=roles/editor OR bindings.role=roles/viewer" \
  --format="value(bindings.role, bindings.members)"

Each row is a role and the principals holding it. Watch for service accounts in the list: default service accounts may have received Editor automatically when their API was enabled.

One finding per role, per project

ZopNight reads the project IAM policy and represents each distinct role in it as its own record, scoped to that project. Records for roles/owner, roles/editor and roles/viewer are marked as basic roles, and each of those raises one finding. A project that uses all three gets three findings; ten Editor members still produce a single Editor finding. No usage data or time window is involved.

What the rule leaves to other checks

Predefined and custom roles never trigger this rule, however broad they are. Predefined roles bound at the project level that could be scoped to a single resource are handled by GCP IAM Project-Level Role Binding, and service accounts holding admin-level roles by GCP Service Account Has Admin Role. Grants made on a folder or the organization are not read as part of the project.

Blast radius, not a saving

The saving is $0. The risk is what a single compromised member can do: with Editor, delete almost anything in the project; with Owner, also grant themselves or others more access.

Replacing basic roles with narrow ones

1. For each member, work out what they actually do. Google’s role recommendations flag unused permissions and suggest smaller roles.
2. Grant the matching predefined roles, for example roles/storage.objectCreator for a member that only uploads files, or a custom role.
3. Remove the basic role with gcloud projects remove-iam-policy-binding PROJECT_ID --member=MEMBER --role=roles/editor.
4. Test that applications and people can still do their jobs. The finding closes on the next inventory once no member holds the role.