What Is IAM in GCP? Google Cloud IAM Explained for Beginners

What IAM is, in plain terms

IAM answers one question for every request made to Google Cloud: Is this identity allowed to perform this action on this resource?

Without a system like IAM, access to cloud infrastructure becomes chaotic fast. You share credentials, give everyone the same account, or make things public and hope for the best. IAM replaces all of that with a structured model: you define exactly who can do exactly what, on exactly which resource. Every access decision is enforced automatically, and every action is logged.

How IAM works in GCP

When you (or an application) try to do something in GCP, IAM evaluates the request through these steps:

1. A principal makes a request. This could be a user clicking in the Console, a gcloud command you run, or an application calling a GCP API.

2. GCP identifies the principal. Who is making this request? A Google account, a service account, a group?

3. GCP identifies the resource. What is being acted on? A specific Cloud Storage bucket? A Compute Engine VM? A BigQuery dataset?

4. GCP checks the IAM policy on the resource. The policy lists all bindings: which roles are granted to which principals on that resource.

5. GCP checks inherited policies. Bindings from parent resources (the project, folder, or organisation above the resource) are also evaluated. The effective policy is the combination of all bindings at all levels.

6. GCP checks whether any matching role includes the required permission. If the principal has a role containing the permission for this action, the request is allowed. If not, it is denied with a permission error.

7. The result is logged. Cloud Audit Logs records who did what, on which resource, and when. Both successful and denied requests are recorded.

The core IAM building blocks

IAM has six core concepts. Understanding each one makes the rest of IAM much easier to reason about.

Principals

A principal is the identity making a request: the “who” in the IAM model. Principals can be humans, applications, or special identifiers. Every IAM binding grants a role to a principal.

Roles

A role is a named collection of permissions: the “what” in the IAM model. You never grant individual permissions directly in GCP; you always grant a role. See IAM Roles Explained for a full breakdown of role types and how to choose the right one.

Permissions

A permission is a single allowed action. Permissions follow the format service.resource.verb. For example:

• storage.objects.get: read a Cloud Storage object
• compute.instances.start: start a Compute Engine VM
• run.services.invoke: call a Cloud Run service

You cannot grant permissions directly. You grant a role that contains the permissions you need. Roles exist specifically to group related permissions so you do not have to manage hundreds of individual entries.

Resources

A resource is the GCP entity the action is performed on: the “where” in the IAM model. Resources include projects, Cloud Storage buckets, BigQuery datasets, Compute Engine VMs, Cloud Run services, and hundreds more. IAM can be applied at the level of an individual resource, or at higher levels (project, folder, organisation) where it is inherited downward.

Bindings

A binding connects a principal to a role on a specific resource. It is the actual access grant. “Alice has the role roles/storage.objectViewer on the bucket my-data” is a binding. Bindings can optionally include a condition that adds time or attribute constraints to limit when the binding is active.

Policies

A policy is the complete set of bindings attached to a resource. Every project, folder, organisation, and many individual resources have their own IAM policy. When IAM evaluates a request, it reads the policy on the target resource and all parent policies above it to determine the effective permissions. See IAM Policy Structure for how policies are structured as JSON and how to avoid accidental overwrites.

Types of principals in GCP

IAM supports four types of principal:

• Google account: a human user identified by their email address. Example: alice@example.com. Managed through Google Workspace or a personal Google account. See Cloud Identity Overview for how to manage human identities at scale across an organisation.

• Service account: a non-human identity for applications, VMs, and automated pipelines. Example: backend-api@my-project.iam.gserviceaccount.com. Service accounts authenticate using short-lived tokens rather than passwords. See Service Accounts for a full guide.

• Google Group: a group email representing a collection of users. Granting a role to a group applies it to all members. Add or remove a person from the group and their access changes automatically. No IAM policy edits needed. This is the recommended approach for team access.

• Special identifiers: allUsers means anyone on the internet, authenticated or not. allAuthenticatedUsers means any signed-in Google account. These are useful for genuinely public content, like a static website served from Cloud Storage, but should never be applied to anything containing sensitive data.

Types of IAM roles

GCP has three categories of role. Choosing the right category is one of the most important IAM decisions you will make.

Basic roles

Basic roles (Owner, Editor, and Viewer) are the original GCP roles. They are project-wide, applying to almost every service in your entire project, and coarse-grained, each granting hundreds of permissions across many services.

Predefined roles

Google maintains hundreds of service-specific predefined roles. Each grants a narrow, well-defined set of permissions for a specific job function. These are the right choice for almost every real-world situation:

• roles/storage.objectViewer: read Cloud Storage objects, nothing else
• roles/storage.objectCreator: create objects; cannot read or delete existing ones
• roles/run.invoker: call a Cloud Run service endpoint
• roles/bigquery.dataViewer: read BigQuery dataset contents
• roles/logging.viewer: read Cloud Logging entries
• roles/compute.instanceAdmin.v1: manage Compute Engine VMs

When choosing a predefined role, pick the narrowest one that covers the actual access needed. Run gcloud iam roles describe roles/ROLE_NAME to see exactly what permissions a role includes before granting it.

Custom roles

Custom roles let you hand-pick individual permissions from GCP’s full list. Use them when no predefined role fits closely enough, for example when a predefined role grants write access but you only need read on one specific resource type. Custom roles require ongoing maintenance as GCP services evolve. Prefer predefined roles where they are a close enough fit.

For a detailed guide on comparing role types, see Basic vs Predefined vs Custom Roles and IAM Roles Explained.

IAM inheritance and scope

IAM policies are inherited through the GCP resource hierarchy. That hierarchy has four levels, from top to bottom:

1. Organisation: the root of your entire GCP setup, tied to your company domain
2. Folders: optional groupings of projects (for example: Production, Development)
3. Projects: the primary boundary for resources, billing, and access
4. Resources: individual services such as Cloud Storage buckets, VMs, and databases

A binding set at any level is inherited by everything below it. If you grant a user roles/viewer at the organisation level, they have that role across every folder, project, and resource in your entire GCP setup. That is usually not what you want.

When to use IAM: practical scenarios

IAM shows up in every real GCP project. Here are common situations you will encounter and how IAM solves them:

• A developer needs to read application logs: grant roles/logging.viewer on the project. Do not give them project Viewer, Editor, or Owner. Those grant access far beyond what is needed.

• An application needs to upload files to Cloud Storage: create a service account, grant it roles/storage.objectCreator on the specific bucket (not the whole project), and attach the service account to the application’s runtime environment.

• A CI/CD pipeline needs to deploy to Cloud Run: grant the pipeline’s service account roles/run.developer scoped to the specific Cloud Run service, not the whole project. See Managing IAM with Terraform for how to define this reproducibly in code.

• A contractor needs access for two weeks: add an IAM condition with an expiry date. When the date passes, the binding stops working automatically. No one needs to remember to revoke it.

• Your team of 20 developers all need read access to BigQuery: create a Google Group, add the team, and grant roles/bigquery.dataViewer to the group. When someone joins or leaves the team, update the group. No IAM policy changes needed.

Least privilege in practice

Least privilege means granting only the minimum access needed to do the job. It is the single most important IAM principle for building secure systems.

How to apply least privilege in practice:

• Start with the most restrictive role that fits the task
• Scope bindings to the narrowest resource that makes sense — bucket level beats project level
• Use Google Groups instead of individual user bindings to simplify lifecycle management
• Use IAM conditions to add time limits to temporary access grants
• Review IAM policies periodically. Bindings accumulate, people leave, requirements change.

For a practical guide to applying this principle in real GCP architectures, see Least Privilege in GCP.

IAM conditions

IAM conditions make a binding conditional on additional attributes. Rather than a simple “Alice has this role” grant, you can say “Alice has this role, but only until Friday” or “this service account has this role, but only for resources tagged as environment:dev”.

Common uses:

• Temporary access: add an expiry date to a binding. Useful for contractors, incident responders, or on-call coverage. The binding stops working after the date with no manual revocation required.

• Resource attribute restrictions: grant a role only for resources with a specific label or in a specific region. Useful for separating dev and production access within the same project.

• IP-based restrictions: allow access only from specific IP ranges, adding a layer of control beyond just the identity.

Conditions use the Common Expression Language (CEL) syntax and are available on most GCP resource types. See IAM Conditions for examples and a full breakdown of what is supported.

IAM vs service accounts

This distinction trips up many beginners. IAM and service accounts are not the same thing, but they work closely together:

• IAM is the access control system. It manages all the rules about who can do what on which resource. IAM does not care what type of identity you are. It just checks whether a binding grants the required permission.

• Service accounts are a type of identity (principal). They are non-human identities designed for applications, VMs, and automated pipelines. IAM grants roles to service accounts exactly as it grants roles to human users.

For a full guide on service accounts, see Service Accounts. For the difference between human and non-human identities in GCP, see User Identities vs Service Accounts.

Viewing and setting IAM policies

The most common IAM operations with gcloud:

# View all IAM bindings on a project
gcloud projects get-iam-policy my-project-id

# Grant a predefined role to a user on the project
gcloud projects add-iam-policy-binding my-project-id \
  --member="user:alice@example.com" \
  --role="roles/logging.viewer"

# Grant a role to a service account on the project
gcloud projects add-iam-policy-binding my-project-id \
  --member="serviceAccount:backend-api@my-project-id.iam.gserviceaccount.com" \
  --role="roles/run.invoker"

# Grant a role scoped to a specific resource (bucket-level, not project-level)
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

# Remove a role from a user
gcloud projects remove-iam-policy-binding my-project-id \
  --member="user:alice@example.com" \
  --role="roles/logging.viewer"

For a complete reference on IAM commands and safe patterns for policy updates (including how to avoid accidental overwrites using etags), see Managing IAM with gcloud. For infrastructure-as-code approaches, see Managing IAM with Terraform.

Audit logging

Every IAM-controlled action in GCP is eligible for audit logging. These logs capture who called which API, what resource was affected, when it happened, and from which IP address.