IAM is the part of Google Cloud that controls access, so that the right identities have the right permissions on the right resources.

The simple definition

IAM is a service built into Google Cloud that lets administrators decide who can take which actions on which resources. The word “who” can mean a person, a group of people, an application or a machine. The word “actions” can mean reading a file, starting a virtual machine, deleting a database or changing another person’s access. The word “resources” can mean almost anything in Google Cloud: a storage bucket, a project, a dataset, a topic, a cluster, or even the whole company account.

Why it exists

When a company first moves to the cloud, it is tempting to give everybody full power so nothing gets blocked. That feels fast, but it is dangerous. A single mistake by one engineer can delete production data. A single stolen password can expose everything. A single over-trusted program can be abused by an attacker. IAM exists to replace “everyone can do everything” with “everyone can do exactly what their job needs, and nothing more”. This rule is called the principle of least privilege, and it is the heart of cloud security.

Where it is used

Every single request in Google Cloud passes through IAM, whether it comes from the console, the command line, a program or another Google service. Security teams use it to protect sensitive data. Developers use it to give applications safe access to databases. Auditors use it to prove who could do what. Because it is built in, there is nothing to install and no separate server to run.

Almost everything in IAM is a sentence with three parts, and once you see the pattern, the rest feels natural.

The three-part sentence

An IAM grant always says: this principal has this role on this resource. The principal is the “who”. The role is a bundle of permissions, the “can do what”. The resource is the “on which thing”. For example: the data analysts group has the BigQuery data viewer role on the sales dataset. Read it aloud and it makes perfect sense. That one sentence is stored as a role binding, and a collection of role bindings attached to a resource is called an allow policy.

Authentication versus authorization

Two words are often confused. Authentication answers “who are you?” and is proven by a password, a second factor, a token or a certificate. Authorization answers “what are you allowed to do?” and is decided by IAM policies. Google Cloud first confirms identity and then checks permission. IAM is mainly the authorization system, although it works closely with the identity providers that handle authentication.

Google Cloud arranges resources like a family tree, and access flows down that tree.

The four levels

At the top sits the organization, which represents your whole company and is tied to your company’s identity domain. Below the organization are folders, which you can use to group projects by department, team or environment, and folders can contain other folders. Below folders are projects, which are the basic containers where you create and use resources and where billing and APIs are enabled. Inside projects live the actual resources, such as virtual machines, buckets, databases and queues.

flowchart TD
  O["Organization: company account"]
  F1["Folder: Finance"]
  F2["Folder: Engineering"]
  F3["Folder: Production"]
  P1["Project: payroll"]
  P2["Project: web app"]
  P3["Project: data platform"]
  R1["Resource: storage bucket"]
  R2["Resource: database"]
  R3["Resource: dataset"]
  O --> F1
  O --> F2
  F2 --> F3
  F1 --> P1
  F3 --> P2
  F3 --> P3
  P1 --> R1
  P2 --> R2
  P3 --> R3
        

Why the hierarchy matters for access

An allow policy can be attached at any level. A grant placed on a folder applies to every project and resource below it. A grant placed on a project applies to everything inside the project. A grant placed on one bucket applies only to that bucket. This is called inheritance, and it is both powerful and risky. It saves effort, because one grant at the right level covers many resources, but a grant placed too high can give far more access than intended.

A principal is anyone or anything that can be given access. Google Cloud supports several kinds.

Special public identifiers

Two special values need extra caution. One stands for absolutely everyone on the internet, signed in or not. The other stands for anyone who is signed in with any Google account, including accounts that have nothing to do with your company. Granting a role to either of these makes a resource effectively public. They are sometimes right, for example for a public website bucket, but they should always be a deliberate and reviewed decision.

Every action in Google Cloud maps to a permission, and permissions are what roles are built from.

What a permission is

A permission is the right to perform one specific action on one type of resource. Permission names follow a regular pattern with three parts: the service, the type of resource and the action. For example, a permission might mean “storage, objects, get”, which allows reading a stored file. Another might mean “compute, instances, delete”, which allows removing a virtual machine. Because the names follow a pattern, you can often guess what a permission does just by reading it.

You do not grant permissions directly

In IAM you never attach a single permission to a principal. Permissions are always grouped into roles, and you grant the role. This keeps policies readable. Imagine a policy with five hundred individual permissions; nobody could review it. A policy with five role names can be read in a minute.

Permissions that need extra care

Some permissions are far more powerful than they look. The right to change IAM policies lets a person give themselves or others more access. The right to create keys for a service account can let someone act as that account. The right to act as a service account lets a person borrow its powers. These can all turn a small amount of access into a large amount, so they are called privilege escalation paths. Review who holds them with special attention.

A role is a bundle of permissions. Google Cloud offers three families, and choosing the right family is one of the most important IAM decisions.

How to choose

A good habit is to start with the narrowest predefined role that lets the job work. If that still gives too much, consider a custom role. If a custom role would need constant updates, reconsider whether a predefined role plus a condition could work instead. Google also offers a recommender that watches actual permission use and suggests narrower roles for principals that never use most of what they hold.

An allow policy is the actual document where the grants are stored, and understanding its shape removes a lot of mystery.

What is inside a policy

An allow policy is a list of role bindings attached to one resource. Each binding connects one role to one or more principals and may include a condition. If you read a policy, you will see something like: this role goes to these principals, that role goes to those principals, and so on. A resource has exactly one allow policy, and that policy describes all the direct grants made on that resource.

Policies are about the resource, not the person

An important point is that policies are attached to resources, not to people. To discover everything one person can access, you cannot simply open “their policy”. You must look at the policies of the resources, including inherited ones from parents. This is exactly why special tools such as the Policy Analyzer and the Policy Troubleshooter exist, which we cover later.

What a person can actually do is the combination of every policy that applies to them, from the top of the tree down to the resource.

The union rule

For allow policies, the effective access on a resource is the union, which means the combination, of the allow policy on that resource and the allow policies of all its ancestors. If a person has a viewer role on a folder and an editor role on one project inside it, they can view everything in the folder but also edit that one project. Grants only add; a lower-level allow policy cannot take away an access that a higher level has granted.

flowchart TD
  A["Allow policy on organization"] --> U["Effective allowed access: union of all"]
  B["Allow policy on folder"] --> U
  C["Allow policy on project"] --> U
  D["Allow policy on resource"] --> U
  U --> E["Deny policies checked first and can override"]
        

What this means in practice

A condition turns a plain grant into a smarter one that applies only when certain facts are true.

What conditions can do

A condition is a small logical rule attached to a role binding. The grant only works when the rule evaluates to true. This is sometimes called attribute-based access control, because the decision depends on attributes of the request or the resource, not only on who is asking.

Good uses

Allow policies only add access. Deny policies exist to say “never”, no matter what else is granted.

How deny works

A deny policy lists principals, a set of permissions that are denied to them, and optionally exceptions and a condition. Deny policies can be attached to the organization, to folders and to projects, and they are inherited down the tree like allow policies. When a request arrives, IAM checks deny policies first. If any deny rule matches, the request is refused, even if several allow policies would have permitted it. Deny always wins over allow.

Why deny policies are useful

Allow, deny and organization policy together

People often mix up the three tools. An allow policy gives access. A deny policy removes selected access from selected principals. The Organization Policy Service, covered in a later chapter, does something different: it restricts how resources may be configured, regardless of who is configuring them. Using all three gives defense in depth.

IAM decides who may act. The Organization Policy Service decides what is allowed to exist, whoever is acting.

A different kind of control

The Organization Policy Service lets administrators set constraints on how resources may be configured across the organization, a folder or a project. A constraint is a rule such as “virtual machines may not have public internet addresses”, “resources may only be created in these approved regions”, “service account keys may not be created” or “access may only be granted to people from our own company domain”. Even a person with a very powerful IAM role cannot break these rules, because the rules do not depend on role. They apply to the resource configuration itself.

Constraints that matter for access

How inheritance works here

Organization policies are also inherited down the hierarchy. A rule set at the organization applies to every folder and project below, and lower levels can usually add stricter limits or, where the rule allows it, carefully override. This lets a central team set the baseline once and still let specific teams adapt within safe limits.

IAM is the foundation, but strong designs add other layers so a single mistake does not open the door.

Which tool answers which question

Programs need identities too. Service accounts are how applications prove who they are and receive limited access.

What a service account is

A service account is a special kind of account that belongs to an application or workload, not to a person. A program running on a virtual machine, in a container or in a function uses a service account to call other Google Cloud services, such as reading a file from storage or writing a row to a database. A service account has two sides. It is a principal, meaning it can be granted roles to act on other resources. It is also a resource, meaning other principals can be granted roles to manage it or to act as it.

Kinds of service accounts

Why service accounts are a prime target

Attackers love service accounts because they often hold strong, long-lived access and are not protected by a second factor. A leaked key for a powerful service account can be used from anywhere in the world, at any hour, without a person ever signing in. This is why modern guidance focuses on giving service accounts very narrow roles, avoiding downloaded keys, and watching their use.

There are several ways for a program to use a service account, and they differ greatly in safety.

From riskiest to safest

The two special roles to understand

Federation lets programs outside Google Cloud, and pods inside clusters, receive access without carrying secret keys.

Workload identity federation

Imagine a program running in another cloud or in your own data center that needs to read a file from Google Cloud storage. The old way is to download a service account key and store it next to the program. The modern way is workload identity federation. The program already has an identity in its own environment, such as a token issued by its cloud provider or a company identity system. It presents that token to Google’s security token service, which checks it against a trust relationship you set up in advance, and returns a short-lived Google access token. The program uses that token for a short time and then asks again. No long-lived Google secret ever exists outside Google Cloud.

flowchart LR
  A["Workload in other cloud or data center"] --> B["Its own identity token"]
  B --> C["Google security token service checks the trust setup"]
  C --> D["Short lived Google access token"]
  D --> E["Access to allowed Google Cloud resources"]
        

Workload identity for Kubernetes

Containers running in Google Kubernetes Engine face a special problem. Many pods share the same machines, so giving the machine one powerful service account would give every pod the same power. Workload identity for Kubernetes solves this by linking each Kubernetes service account to a specific identity, so each pod gets only the access its own application needs, using short-lived credentials supplied automatically. Different workloads on the same node can therefore hold different permissions.

Before a person can receive a role, they need a trustworthy identity, and that identity needs to be managed throughout their time at the company.

Where human identities come from

Most companies manage employees through Google Workspace or Cloud Identity. These services hold the user accounts and groups, enforce password rules and second-step verification, and form the foundation of the organization in Google Cloud. When an employee joins, you create the account and add them to the right groups. When they leave, you suspend or remove the account and their access ends everywhere at once.

Single sign-on and external providers

Many companies already have a main identity provider that holds all employees. Instead of creating a second set of accounts, they connect Google Cloud to it so people sign in with their usual company login. This gives one place to enforce multi-factor authentication and one place to remove access when someone leaves.

Groups make access manageable, and careful delegation keeps no single person too powerful.

Why groups are the main tool

Granting roles to individuals does not scale. If you have two hundred engineers and fifty projects, direct grants quickly become impossible to review. With groups, you define a small number of groups that match job functions, grant roles to the groups, and manage people by changing membership. A policy then contains a handful of readable group names instead of hundreds of email addresses.

A sensible group design

Separation of duties

For sensitive work, no single person should be able to complete the whole process alone. The person who writes code should not be the only one who can release it to production. The person who creates users should not be the only one who can approve their powerful roles. In IAM terms, this means splitting dangerous permissions across different groups so that two people must cooperate, which greatly lowers the risk of both mistakes and abuse.

Follow a single request step by step to see how Google Cloud reaches its yes or no decision.

flowchart TD
  A["Request arrives with an identity"] --> B["Identity is authenticated"]
  B --> C["Organization policy and boundaries checked"]
  C --> D{"Any deny rule matches?"}
  D -- "Yes" --> X["Request refused"]
  D -- "No" --> E["Collect allow policies from resource and ancestors"]
  E --> F["Include roles from groups and conditions"]
  F --> G{"Does a granted role contain the needed permission?"}
  G -- "No" --> X
  G -- "Yes" --> H["Request allowed and logged"]
        

Access should have a beginning, a review and an end. Treat every grant as something with a life, not a permanent fact.

Revocation is not always instant

Two things deserve attention. First, because IAM is eventually consistent, a removal may take a little time to be effective everywhere. Second, credentials that were already issued, such as short-lived tokens, remain valid until they expire. In an emergency, such as a suspected compromise, you should remove the access, disable or delete the affected service account or keys, and rotate anything that might have been exposed, rather than only waiting for the policy change to settle.

Google Cloud includes several helpers that answer the hardest IAM questions without guesswork.

A healthy review loop

Good access control is only half the job. The other half is being able to prove, afterwards, what actually happened.

The main kinds of audit logs

What a good record answers

An audit entry tells you who made the call, which method they called, which resource it affected, from which network address, when it happened and whether it was allowed. When service account impersonation is used, the record also shows both the original caller and the account that was used, which makes it possible to trace actions back to a real person.

Access is never finished. It drifts over time, so it needs watching, alerting and regular review.

Alert on the changes that matter

Because every IAM change is written to the audit logs, you can build alerts that tell the security team the moment something risky happens. The aim is to be told about rare and serious events, not to be flooded with every ordinary change.

Regular access reviews

A short list of habits that prevents most real-world cloud access incidents.

The core habits

• Least privilege. Give the narrowest role that lets the job work, on the lowest resource that makes sense.
• Prefer predefined roles over basic roles. Avoid the owner and editor basic roles in production, especially for service accounts.
• Use groups. Grant to groups that match jobs, and manage people through membership.
• Avoid service account keys. Use attached accounts, impersonation and federation instead, and block key creation by organization policy.
• One service account per workload. Never share a powerful account between unrelated applications.
• Protect administrators. Use strong multi-factor authentication, separate administrator accounts from daily accounts and keep the number of powerful people small.
• Use temporary access. Prefer time-limited grants and approval-based elevation over permanent powerful roles.
• Add guardrails. Use organization policies and deny policies to block the riskiest actions across the whole company.
• Log and alert. Keep audit logs in a protected place and alert on risky IAM changes.
• Review regularly. Use recommendations and access reviews to remove unused permissions.

Organizations that manage access well tend to repeat a few simple designs.

These common mistakes appear again and again in real incidents and audits.

The same IAM tools solve very different problems depending on the kind of organization.

IAM is powerful, but it has costs and limits that every designer should know.

Choosing the right control

No single tool does everything. The strongest designs layer them, so that a mistake in one layer is caught by another. Strong access control combines good identity, narrow grants, guardrails, monitoring and regular review.

Everyone meets a permission error sooner or later. A calm, ordered approach finds the cause quickly.

Access rules written down, reviewed and applied by a pipeline are far safer than rules clicked in a console.

Why write access down

When access is changed by hand in a console, there is no review, no history and no easy way to rebuild. When access is described in configuration files stored in version control, every change has an author, a reason and a reviewer. A pipeline applies the changes consistently. If someone makes a manual change outside the process, it can be detected and reversed.

You do not need a perfect design on day one. Build in stages, starting with the controls that remove the largest risks.

How to know it is working

Signs of a healthy setup include few people with powerful roles, no service account keys in use, nearly all access flowing through groups, quick and clear answers to the question “who can access this?”, alerts that fire rarely and are always acted on, and access reviews that complete on time with little surprise.

The role catalog is large, but a small group of roles appears in almost every organization, and knowing them helps you spot risk quickly.

Role names and exact contents can change as Google updates services, so always confirm details in the current documentation. The list below explains the purpose of common roles in plain language and how carefully each should be handled.

Roles that deserve extra protection

Many access problems begin with a small wrong belief. Clearing these up early saves a great deal of trouble later.

Notice that every one of these misconceptions leads to either too much access or too little visibility. The cure is the same each time: understand the model, check effective access with the right tools, keep grants narrow and temporary, and review regularly.

A quick reference for the words used in this guide, in alphabetical order.

Cloud Identity manages the people: user accounts, groups and sign-in rules. IAM decides what those identities may do on Google Cloud resources. One proves who you are and keeps the directory, the other decides what you are allowed to touch.

They are convenient for tiny experiments, but they carry thousands of permissions across all services. In production, prefer predefined roles for the specific services you use, and use custom roles only when predefined ones are still too broad.

Access may still reach them through a group, through a grant at a higher level in the hierarchy, or through another role. Also, changes take a short time to spread, and tokens already issued remain valid until they expire. Use the troubleshooter to see every route.

A deny policy blocks specific permissions for specific principals, so it is about who may do what. An organization policy restricts how resources may be configured whoever is acting, so it is about what is allowed to exist.

A key is a long-lived secret that can be copied and used from anywhere without any other check. If it leaks, an attacker has lasting access. Attached accounts, impersonation and federation use short-lived credentials and avoid storing secrets at all.

Add a time-based condition to the role binding so it expires by itself, or use an approval-based elevation feature that grants powerful access for a short, recorded period. Either way, avoid leaving manual temporary grants without an end date.

At the lowest level that still meets the need. Use the organization level for a few company-wide administrators, folders for shared team and environment access, projects for most daily work, and individual resources for narrow exceptions.

Policies are attached to resources, not to people, so you need a tool that combines inherited policies and group memberships. Policy Analyzer and Cloud Asset Inventory are built for this question, and the troubleshooter helps with a single principal and permission.

Yes. With workload identity federation the program presents a token from its own environment, which Google exchanges for a short-lived access token based on a trust you configure. No long-lived Google secret has to be stored outside Google Cloud.

Not always. IAM is eventually consistent, so a change usually takes effect within a couple of minutes but can occasionally take longer. After granting or removing access, wait briefly and retry, and in emergencies also revoke credentials, not just policies.

It means choosing the narrowest role that makes the job work, at the lowest sensible level, for the shortest time needed. Over time, you also use usage data and recommendations to remove permissions that nobody actually uses.

IAM is the foundation but not the whole defense. Combine it with strong sign-in, organization policies, deny rules, perimeters such as VPC Service Controls, encryption, logging and alerting, and regular reviews so that one mistake does not expose everything.

Identity and Access Management in Google Cloud answers one question for every request: may this identity do this action on this resource? It does so through a simple model of principals, roles and resources, stored as allow policies that flow down the resource hierarchy, refined by conditions, limited by deny rules and guardrails, and recorded in audit logs. Programs use service accounts, preferably through attachment, impersonation and federation instead of keys. People are managed through groups and a trusted identity provider. Good IAM is less about clever features and more about steady habits: narrow grants, short lifetimes, clear ownership and regular review.

Remember the hotel from the beginning. Nobody gets a master key. Each person receives a card that opens only what their job needs, only for as long as they need it, and every door keeps a record of who passed through.

A short self-check for your own environment

Ask yourself a few questions. Can you name everyone who holds a powerful role on your organization, and is that list short? Do any service account keys exist, and if so, who owns them and why? Is access granted to groups rather than individuals? Are risky actions such as public sharing blocked by policy? Would you be alerted if someone granted themselves an administrator role tonight? If any answer is uncertain, that is where to begin.