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.

What is the GCP IAM Predefined Roles Reference?

Searchable reference for Google Cloud predefined IAM roles covering Compute, Storage, BigQuery, GKE and project basic roles with their role IDs and permission scope. It runs free in your browser on Gera Tools, with nothing uploaded.

GCP IAM Predefined Roles Reference

Name: GCP IAM Predefined Roles Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click 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.

Quick reference: most-used predefined roles by service

Cloud Storage

Role ID	What it grants
`roles/storage.objectViewer`	Read objects and metadata
`roles/storage.objectCreator`	Create/upload objects (no read)
`roles/storage.objectAdmin`	Full CRUD on objects, not buckets
`roles/storage.admin`	Full control including bucket management

BigQuery

Role ID	What it grants
`roles/bigquery.dataViewer`	Read table data and metadata
`roles/bigquery.dataEditor`	Read, create, update, delete table data
`roles/bigquery.jobUser`	Run queries (create jobs) — needed alongside dataViewer
`roles/bigquery.admin`	Full BigQuery control

Compute Engine

Role ID	What it grants
`roles/compute.viewer`	Read-only view of all Compute resources
`roles/compute.instanceAdmin.v1`	Manage VM instances
`roles/compute.networkAdmin`	Manage networks, firewall rules
`roles/compute.admin`	Full Compute control

GKE / Kubernetes Engine

Role ID	What it grants
`roles/container.viewer`	Read GKE cluster configurations
`roles/container.developer`	Deploy to clusters (no cluster create/delete)
`roles/container.clusterAdmin`	Full cluster management

The three-level hierarchy of members

IAM binds roles to members, which can be:

User accounts (user:[email protected]): individual Google accounts
Service accounts (serviceAccount:[email protected]): non-human identities for apps and VMs
Groups (group:[email protected]): Google Groups, useful for managing access by team
Domain (domain:example.com): everyone in a Google Workspace domain

For production workloads, prefer service accounts with predefined roles bound at the narrowest scope. Granting your application’s service account roles/storage.objectViewer on a specific bucket rather than project-wide limits the blast radius if the account is compromised.

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.
Audit bindings with gcloud projects get-iam-policy <project> to review who has what access.