Basic Roles vs Predefined Roles vs Custom Roles

Overview

Google Cloud IAM offers three types of roles for granting permissions to principals:

1. Basic roles — legacy, very broad (Owner, Editor, Viewer).
2. Predefined roles — Google-maintained, scoped per service (roles/storage.objectViewer).
3. Custom roles — your own, with a chosen permission set.

Choosing the right type — and the right scope — is one of the most consequential decisions in Google Cloud security.

---

1. Basic Roles

Basic roles existed before predefined roles and grant wide-ranging permissions across many services.

Roles

• roles/owner — full control of all resources, including billing and IAM.
• roles/editor — can modify almost all resources (no IAM).
• roles/viewer — read access to almost all resources.
• roles/browser — minimal directory navigation.

Why They're Discouraged

• Cross-service breadth — Editor / Viewer apply across thousands of services in your project / org.
• No service-level granularity — you cannot say "Editor on Storage but only Viewer on BigQuery."
• Permission creep over time — as new services launch, basic roles automatically include their permissions.
• Compliance risk — auditors flag basic roles in production.

When to Use

• Sandbox / test projects only.
• Initial setup before predefined / custom are configured.
• Never in production.

---

2. Predefined Roles

Predefined roles are created and maintained by Google, scoped per service:

• roles/storage.objectViewer
• roles/compute.instanceAdmin
• roles/bigquery.dataEditor
• roles/iam.serviceAccountTokenCreator

Why They're Recommended

• Service-scoped — narrower than basic roles.
• Maintained by Google — updated as services evolve.
• Documented permissions — you can see exactly what they grant.
• Right-fit options — most services offer Viewer / Reader / Editor / Writer / Admin tiers.

Considerations

• Some predefined roles are still broad (e.g., service-level admin).
• Always check the included permissions list; some surprise you.

Examples

Role	Includes
roles/storage.objectViewer	Read GCS objects
roles/storage.objectAdmin	Full GCS object control
roles/storage.admin	Full Storage service control (buckets + objects + IAM)
roles/bigquery.dataViewer	Read BigQuery data (no jobs)
roles/bigquery.user	Run queries + create datasets
roles/iam.serviceAccountUser	Use a service account for resources

---

3. Custom Roles

Custom roles let you bundle exactly the permissions you choose at Organization or Project scope.

When to Use

• No predefined role fits the workload need.
• Want stricter least privilege than predefined offers.
• Need consistent role across multiple workloads/services.

Example

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

Considerations

• You own the maintenance — when GCP adds new permissions or refactors, you must update.
• Custom roles can suffer from permission creep like basic roles if not reviewed.
• Org-scoped custom roles usable in any project; project-scoped only in that project.
• Quota: 300 custom roles per org / project.

Custom Role Lifecycle

• Define in Git (Terraform / yaml).
• Peer review changes.
• Quarterly review for permission creep.
• Document purpose and intended principals.

---

Side-by-Side Comparison

Aspect	Basic	Predefined	Custom
Scope	Project / Org	Per service	Org or Project
Maintained by	Google	Google	You
Granularity	Coarse	Fine	Fine (your choice)
Maintenance burden	None	None	Yours
Best for	Avoid in prod	Default for most cases	Specific bespoke needs
Risk	Very high	Moderate	Depends on definition

---

Decision Guide

1. Does a predefined role fit? Use it.
2. Is the predefined role too broad? Define a custom role with the needed permissions.
3. Tempted to use Editor for convenience? Stop. Pick the smallest predefined role; iterate based on observed usage.
4. Tempted to use Owner? Almost never the right answer outside emergency / break-glass.

---

Common Mistakes

• Owner / Editor at Org level — full or near-full reach across the org.
• Custom role bloat — too many permissions, becomes Editor-like.
• Predefined role chosen by name without checking permissions.
• Custom roles defined ad-hoc in console without version control.
• Stale custom roles never reviewed.
• Mixing custom and predefined for same use case — fragmented policy.

---

Real-World Examples

1. Editor Cleanup

A startup audit revealed 60 of 75 production bindings were Editor at project level. They migrated to specific predefined roles per workload and tightened least privilege; effective permissions dropped 80%.

2. Custom Role for Data Pipeline

A data team needed an unusual permission combination. They defined DataPipelineRunner custom role with exactly the needed permissions; no over-permissioning.

3. Predefined Role Surprise

roles/cloudfunctions.developer includes the ability to set the function's service account, which can lead to privilege escalation if combined with Token Creator. The team migrated to a custom role excluding that permission.

4. Stale Custom Role

A custom role created 3 years ago for a deprecated workload still had bindings. Audit revealed the role granted access to a sensitive resource. Removed in cleanup.

---

Best Practices

1. Default to predefined roles.
2. Use custom roles when no predefined fits.
3. Avoid basic roles in production.
4. Define custom roles in IaC (Terraform).
5. Peer review custom role changes.
6. Quarterly review of custom role permissions.
7. IAM Recommender to identify role over-permissioning.
8. Document role purpose.
9. Group-based bindings for lifecycle hygiene.
10. Audit log on role changes.

---

Checklist

• No basic roles in production?
• Predefined roles preferred?
• Custom roles in IaC and version-controlled?
• Quarterly custom role review?
• Role purpose documented?
• Audit alerts on role changes?
• IAM Recommender findings actioned?

---

How Forestall Helps

Forestall analyzes role assignments and effective usage:

• Identifies basic role assignments.
• Surfaces over-broad custom roles.
• Recommends predefined / custom role alternatives based on actual usage.
• Detects role bloat and stale custom roles.

---

Frequently Asked Questions

Are basic roles still supported?

Yes, but discouraged for least privilege.

Are custom roles always best?

No — predefined are maintained by Google. Use custom only when needed.

Can custom roles include all permissions?

No — some sensitive permissions (iam.organizationRoles.*) are restricted from custom roles.

Can predefined roles change?

Google may add or remove permissions over time. Track changes (release notes) for security-sensitive roles.

How many custom roles can I have?

300 per project, 300 per org (subject to quota changes). Plenty for most needs; design with reuse in mind.

---

Conclusion

Choosing the right Google Cloud role type — usually predefined, sometimes custom, rarely basic — is foundational to GCP least privilege. Treat custom roles as code, review them regularly, eliminate basic roles from production, and use Recommender to catch over-permissioning. With a thoughtful role strategy, IAM bindings stay tight and intent-aligned even as your GCP environment grows.