The Core IAM Model: Who, What, and Which Resource
Google Cloud IAM answers three questions for every access decision: who is making the request (a principal — a user, group, service account, or domain), what can they do (a role, which is a bundle of permissions like storage.objects.get), and on which resource is that role granted (a project, folder, organization, or individual resource like a specific bucket). An IAM policy is the JSON/YAML document that binds principals to roles at a given resource scope, and GCP evaluates access by checking whether any policy binding at that resource or an ancestor in the resource hierarchy grants the required permission, since permissions are additive and inherited downward through the hierarchy.
Cricket analogy: IAM roles are like an IPL franchise assigning specific responsibilities: Rohit Sharma is granted the 'captain' role with permissions to set fields and make bowling changes, while a net bowler only has permission to bowl in practice, not to make team decisions.
Predefined, Basic, and Custom Roles
GCP offers three role categories: basic roles (Owner, Editor, Viewer) which are broad, legacy roles that grant sweeping permissions across nearly every service and are discouraged in production because they violate least privilege; predefined roles, which are curated by Google per service (like roles/storage.objectViewer or roles/compute.instanceAdmin) to grant just the permissions needed for a specific job function; and custom roles, which let an organization assemble an exact set of permissions when no predefined role fits, at the cost of needing to maintain that role as GCP adds new permissions over time. Best practice is to grant the narrowest predefined role that satisfies the need, and reserve custom roles for genuinely unique requirements rather than as a default choice.
Cricket analogy: A basic 'Owner' role is like giving a substitute fielder full captaincy powers just to field for one over — wildly excessive — whereas a predefined role is like a specialist role such as 'designated powerplay bowler' matched precisely to the job.
Conditional Bindings and IAM Recommender
IAM Conditions let you attach a CEL (Common Expression Language) expression to a role binding so access is only granted when the condition evaluates true, commonly used for time-bound access (e.g., grant a role only until a specific expiry date for a contractor) or resource-attribute restrictions (e.g., only for resources with a specific tag). IAM Recommender continuously analyzes actual permission usage over the past 90 days and suggests role downgrades when it detects that a principal is using far fewer permissions than their current role grants, which is one of the most effective tools for tightening over-privileged bindings without manually auditing every grant.
Cricket analogy: A time-bound IAM condition is like the BCCI granting a stand-in captain authority only for the duration of a single series while the regular captain like Rohit Sharma is injured, automatically expiring afterward.
# Grant a predefined role scoped to a single project
gcloud projects add-iam-policy-binding my-project \
--member="user:priya@example.com" \
--role="roles/storage.objectViewer"
# Grant a time-bound conditional role for a contractor
gcloud projects add-iam-policy-binding my-project \
--member="user:contractor@example.com" \
--role="roles/compute.viewer" \
--condition='expression=request.time < timestamp("2026-08-31T00:00:00Z"),title=contractor-expiry'IAM policies are evaluated additively and inherited down the resource hierarchy (Organization > Folder > Project > Resource); there is no explicit 'deny' in standard IAM roles, though IAM Deny policies exist as a separate mechanism for hard blocklists that override allow grants.
Assigning the basic Editor role to a service account is a frequent audit finding because Editor grants near-full write access across almost every GCP service in the project; always prefer the narrowest predefined or custom role that satisfies the actual job.
- IAM policies bind a principal (user, group, service account) to a role at a specific resource scope.
- Permissions are additive and inherited down the resource hierarchy from Organization to individual resource.
- Basic roles (Owner, Editor, Viewer) are broad and generally discouraged in production environments.
- Predefined roles offer curated, service-specific permission sets aligned to common job functions.
- Custom roles allow precise permission sets but require ongoing maintenance as GCP evolves.
- IAM Conditions use CEL expressions to scope bindings by time, resource attributes, or other context.
- IAM Recommender analyzes usage patterns to suggest downgrading over-privileged role bindings.
Practice what you learned
1. In the GCP IAM model, what three elements does every access decision depend on?
2. Why are basic roles like Owner and Editor discouraged in production environments?
3. How does IAM permission inheritance work across the resource hierarchy?
4. What technology do IAM Conditions use to express restrictions like time-bound access?
5. What does IAM Recommender primarily help with?
Was this page helpful?
You May Also Like
Service Accounts Explained
How GCP service accounts give identity to workloads instead of humans, and best practices for keys, impersonation, and workload identity.
Cloud KMS Basics
An introduction to Google Cloud Key Management Service for creating, managing, and using encryption keys to protect data at rest.
Cloud SQL Basics
An introduction to Google Cloud SQL, GCP's fully managed relational database service for MySQL, PostgreSQL, and SQL Server.