What is a Google Cloud Role?

Definition

A Google Cloud Role is a named collection of permissions that can be granted to a principal via a policy binding. Roles are how you tell GCP "this principal can do these things on this resource."

In simple terms:

A role is a bundle of permissions you assign to principals.

---

Why Roles Matter

• Roles are the unit of permission grant in GCP.
• Choosing the right role determines whether your principals follow least privilege or drift toward over-permissioning.
• Misuse of basic roles is a top GCP misconfiguration.

---

Role Types

1. Basic Roles (Legacy)

• Owner (roles/owner)
• Editor (roles/editor)
• Viewer (roles/viewer)
• Browser (roles/browser) — minimal browse-the-hierarchy access.

These existed before predefined roles; each contains thousands of permissions across services. Strongly discouraged in production.

2. Predefined Roles

• Created and maintained by Google.
• Scoped per service: roles/storage.objectViewer, roles/compute.instanceAdmin, roles/bigquery.dataEditor, etc.
• Hundreds of predefined roles across services.
• Default starting point for least privilege.

3. Custom Roles

• Defined by your organization.
• Scoped at Organization or Project level.
• Bundle exactly the permissions you choose.
• Use when no predefined role fits and you want to enforce a specific permission set.

---

Common Predefined Role Patterns

By Function

• Viewer / Reader: read-only across a service (roles/storage.objectViewer, roles/bigquery.dataViewer).
• Editor / Writer: read + write data, no admin ops.
• Admin: full service operations (roles/storage.admin, roles/compute.admin).
• Token Creator / Impersonator: identity-related (roles/iam.serviceAccountTokenCreator).

By Resource Granularity

• Many services have multiple admin roles at different scopes (e.g., roles/compute.instanceAdmin.v1 vs roles/compute.admin).

---

Example Custom Role

title: "Bucket Lifecycle Manager"
description: "Manage GCS bucket lifecycle config without object access"
includedPermissions:
- storage.buckets.get
- storage.buckets.update
stage: GA

Assign to operators who manage retention without giving them object read/write.

---

Where Roles Are Bound

• Organization (broadest).
• Folder.
• Project.
• Resource (some services support resource-level bindings).

A role binding includes a principal + role + (optional) condition.

---

Common Mistakes with Roles

• Owner / Editor at Organization or Project level.
• roles/iam.serviceAccountUser broadly assigned — enables passing service accounts.
• roles/iam.serviceAccountTokenCreator broadly assigned — enables impersonation.
• Custom roles bloated to cover many use cases (becoming basic-role-like).
• Custom roles never reviewed as services evolve.
• Predefined role chosen by name without checking permissions — some "Viewer" roles include surprising permissions.

---

Real-World Examples

1. Editor Role on Project = Effective Owner

A user granted roles/editor on a project can change most resources, including IAM in some cases. Treat Editor as nearly Owner.

2. roles/iam.serviceAccountTokenCreator Misuse

A user has Token Creator on prod-deploy-sa (which has Owner). User impersonates → effective Owner. Privilege escalation in one step.

3. Overly Broad Custom Role

"DataTeamRole" was created to cover BigQuery and Storage; over time, permissions accreted (Compute, Cloud Functions, Pub/Sub). It became a near-Editor role for the data team.

4. Predefined Role Surprise

roles/dataflow.developer allows job creation; in some setups, this enables service account impersonation. Always check predefined role permissions before assigning broadly.

---

Best Practices

1. Avoid basic roles in production.
2. Default to predefined roles, scoped per service.
3. Use custom roles when no predefined fits — keep them tight.
4. Bind at smallest scope (resource > project > folder > org).
5. Review custom roles quarterly for permission creep.
6. Avoid Token Creator and Service Account User broadly.
7. IAM Recommender for least-privilege suggestions.
8. Audit for risky predefined role assignments.
9. Document role purpose and intended scope.
10. Group-based assignment for lifecycle hygiene.

---

Checklist

• No basic roles in production?
• Predefined roles preferred?
• Custom roles minimal and reviewed?
• Token Creator / Service Account User constrained?
• Bindings at smallest scope?
• IAM Recommender findings actioned?
• Quarterly custom role review?
• Audit log on role binding changes?

---

How Forestall Helps

Forestall analyzes role usage:

• Identifies basic role assignments to remediate.
• Surfaces over-broad custom roles.
• Detects risky predefined role bindings (e.g., Token Creator).
• Recommends least-privilege role refinements based on observed usage.

---

Frequently Asked Questions

Are basic roles deprecated?

Not formally, but discouraged. Use predefined or custom for any meaningful least privilege.

Can a role be both predefined and custom?

No — they're separate types. Custom roles often start as copies of predefined ones, then narrowed.

Where do I find available roles?

Google Cloud Console → IAM → Roles. Or gcloud iam roles list.

Can custom roles be project- or org-scoped?

Yes — custom roles are defined at Organization (usable in any project) or at Project (usable in that project).

What's the difference between role and permission?

Roles are bundles of permissions. Permissions are atomic actions (storage.objects.get).

---

Conclusion

Roles are how Google Cloud IAM packages permissions for assignment. Avoid basic roles, prefer predefined, use custom carefully, watch out for risky roles like Token Creator and Service Account User, and bind at the smallest necessary scope. With IAM Recommender and continuous review, role hygiene becomes a continuous discipline rather than a one-time chore — and least privilege actually sticks.