What are basic, predefined and custom roles in GCP?

Basic roles (Owner, Editor, Viewer) are broad legacy roles that span all services and are discouraged for production. Predefined roles are curated by Google for a specific service with a least-privilege permission set. Custom roles let you assemble an exact list of permissions you define.

Why avoid the basic Owner and Editor roles?

They grant sweeping access across every API in the project, which violates least privilege and makes audits hard. roles/owner can also change IAM policy and delete the project. Prefer predefined roles scoped to the service and resource a principal actually needs.

What is the difference between objectViewer and objectAdmin in Storage?

roles/storage.objectViewer can read objects and their metadata but not write or delete. roles/storage.objectAdmin has full control over objects (create, read, update, delete) but not over bucket-level IAM. roles/storage.admin adds bucket management on top.

How do I grant read-only BigQuery access?

Grant roles/bigquery.dataViewer to read table data and metadata, and roles/bigquery.jobUser if the principal also needs to run queries (which create jobs). dataViewer alone lets them see data but not execute queries that incur cost.

Can a role be granted at different levels?

Yes. Most predefined roles can be bound at the organization, folder, project or individual resource level, and the binding is inherited downward. Granting roles/storage.objectViewer on a single bucket is far safer than granting it project-wide.

GCP IAM Predefined Roles Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

GCP IAM predefined roles

Google Cloud IAM grants access by binding a role (a bundle of permissions) to a member on a resource. Predefined roles are Google-curated, least-privilege bundles scoped to a single service. This reference lists the most common predefined roles across Storage, Compute, BigQuery, GKE and project basics with their roles/* IDs and what each grants.

How it works

A role is bound with an IAM policy. The role ID is the canonical identifier you pass to tooling:

gcloud projects add-iam-policy-binding my-project \
  --member="user:[email protected]" \
  --role="roles/storage.objectViewer"

Predefined roles follow a naming pattern of roles/<service>.<scope> where the scope is usually one of viewer (read), user/writer (use/write), admin (full control of resources) or <resource>Admin (manage one resource type). Bindings can be set at organization, folder, project or resource level and are inherited downward.

Tips and notes

Avoid the basic roles roles/owner, roles/editor, roles/viewer in production — they span every API.
Bind roles at the narrowest resource scope possible (a single bucket or dataset) rather than project-wide.
Pair data and job roles in BigQuery: dataViewer to read, jobUser to run queries.
Use gcloud iam roles describe roles/<id> to see the exact permission list behind any predefined role.