IAM is Google Cloud’s system for deciding who can do what on which resource.

Google’s documentation describes IAM as a fine-grained authorization system. Authorization means deciding what an already identified person or program is allowed to do. Before any action runs, such as creating a virtual machine or viewing a dataset, IAM checks that the requester has the permissions needed, and blocks the action if they do not.

Every access rule in IAM is built from three simple pieces. The first is a principal, which is the identity receiving access. The second is a role, which is a bundle of permissions. The third is a resource, which is the thing being accessed. You connect the three by granting a role to a principal on a resource. That is the whole idea, and almost everything else in this tutorial is a refinement of it.

Proving who you are is a different step from deciding what you may do.

Beginners often mix up two words that sound alike. Authentication is the step where you prove your identity, for example by signing in with a password and a second verification step. Authorization is the step that follows, where the system checks whether that proven identity is allowed to perform the requested action. IAM is mainly about authorization. Identity systems such as Google Accounts, Cloud Identity, and federation with outside identity providers handle the proving of identity.

sequenceDiagram
  participant U as User or program
  participant A as Identity check
  participant I as IAM
  participant R as Google Cloud resource
  U->>A: Sign in and prove identity
  A-->>U: Identity confirmed
  U->>I: Request an action on a resource
  I->>I: Check policies for permission
  alt Permission found
    I->>R: Allow the action
    R-->>U: Result returned
  else Permission missing
    I-->>U: Access denied
  end
        

A principal is any authenticated identity that can be given access.

Google’s documentation says principals are authenticated identities and notes that they were formerly called members, a word some interfaces and tools still use. It groups them into two families: human users and workloads.

A permission is a single allowed operation, such as listing projects or publishing a message.

Permissions are written in a consistent pattern: the service, then the resource type, then the action. Google’s documentation gives the form as service, resource, and verb joined by dots, and offers the example of a permission that lets a user list Resource Manager projects. Permissions often match one-to-one with the methods of a service’s programming interface, so if an action exists in the interface, a permission usually guards it.

The crucial rule is that you cannot grant a permission directly to a principal. Permissions are only granted by way of roles. This keeps access manageable, because a person sees roles, not hundreds of tiny permissions.

A role groups the permissions needed for a job, and you grant the role.

Google describes three types of role. Predefined roles are maintained by Google Cloud services and designed for common tasks; for example, a Pub/Sub publisher role allows publishing to a topic. Custom roles are created by you and contain only the permissions you choose. Basic roles are broad roles covering many services, intended mainly for testing.

flowchart LR
  P1["Permission: list items"] --> R1["Viewer-style role"]
  P2["Permission: read item"] --> R1
  P1 --> R2["Editor-style role"]
  P2 --> R2
  P3["Permission: create item"] --> R2
  P4["Permission: delete item"] --> R2
  R1 --> U["Principal receives the role"]
  R2 --> U
        

Google Cloud organizes everything in a tree, and access flows down the tree.

Resources are the things you want to protect: virtual machines, storage buckets, datasets, and many more. Google Cloud arranges them in a hierarchy. At the top is the organization, which represents a company. Beneath it are optional folders, used to group projects, for example by department or environment. Beneath folders are projects, which hold your actual resources. Inside projects are the individual service resources.

flowchart TD
  ORG["Organization"] --> F1["Folder: Engineering"]
  ORG --> F2["Folder: Finance"]
  F1 --> P1["Project: Web app dev"]
  F1 --> P2["Project: Web app prod"]
  F2 --> P3["Project: Reporting"]
  P1 --> R1["VM, bucket, dataset"]
  P2 --> R2["VM, bucket, dataset"]
  P3 --> R3["Dataset"]
        

An allow policy is the document that records who has which role on a resource.

An allow policy is attached to a resource. Google’s documentation explains that it contains role bindings that link roles to principals, and that older documents may call it an IAM policy. When someone requests access, IAM checks the allow policy of that resource. If a binding grants a role that contains the required permission to that person, the request is allowed.

Policies are additive

Allow policies only add access. If any binding in the applicable policies grants the permission, the action can be allowed. Removing access therefore means removing the binding that grants it, not adding a rule saying “no” in the same place. For explicit blocking, Google offers a different policy type called deny policies, covered later.

Roles granted on a parent flow down to everything beneath it.

Container resources, namely organizations, folders, and projects, pass their allow policies down to everything below them. Google highlights three benefits. You can grant broad access with one binding, such as giving a security team a role at the organization level. You can reach resources that cannot hold their own policy, such as log buckets, by granting a role on an ancestor project. And you can determine full access by reviewing the effective allow policy, which is the combined set of the resource’s own policy and the policies of all its ancestors.

flowchart TD
  O["Organization policy: Security team can view everything"] --> F["Folder policy: Developers group can deploy"]
  F --> P["Project policy: Intern can read logs"]
  P --> R["Resource: effective access is the union of all three"]
        

Service accounts let applications act in Google Cloud without borrowing a person’s identity.

Applications often need to call Google Cloud services: a web server reading from a database, a nightly job writing to storage. They need an identity to do so. A service account is that identity. Unlike a Google Account, it belongs to an application or virtual machine rather than a person. Google’s documentation lists service accounts as one of the workload principal types.

A service account is both a principal and a resource. It is a principal because it can be granted roles on other resources. It is a resource because other principals can be granted roles on it, such as the ability to use it or to act as it.

flowchart LR
  APP["Application on a virtual machine"] -->|"runs as"| SA["Service account"]
  SA -->|"has role"| B["Storage bucket"]
  SA -->|"has role"| Q["Message queue"]
  SA -.->|"no role"| DB["Database: access denied"]
        

Good habits for service accounts

Federation lets outside identities work in Google Cloud without creating duplicate accounts.

Many companies already have a system that knows their employees, such as a corporate directory. Rather than creating a second set of accounts, Google Cloud can trust that existing system. This is called federation. Google’s documentation names two forms in its list of principals: workforce identity federation for human users, and workload identity federation for programs.

Deny policies block specific permissions even when a role would otherwise allow them.

Allow policies are additive, so by themselves they cannot forbid something. Deny policies fill that gap. As Google describes them, deny policies prevent principals from using certain permissions even if they hold a role that includes those permissions. They give central teams a way to set guardrails that individual project owners cannot override with their own grants.

flowchart TD
  REQ["Request arrives"] --> D{"Deny policy blocks it?"}
  D -->|"Yes"| X["Access denied"]
  D -->|"No"| A{"Allow policy grants it?"}
  A -->|"Yes"| OK["Access allowed"]
  A -->|"No"| X
        

A principal access boundary limits which resources a principal can ever reach.

Google’s overview describes Principal Access Boundary policies as policies that define which resources a principal is eligible to access. A principal cannot reach resources outside that scope, even if a role has been granted on them. Where deny policies block specific permissions, this boundary draws a fence around the set of resources.

Conditions make a grant depend on attributes such as time or the target resource.

Google describes IAM Conditions as attribute-based logic added to policies, including role bindings. A condition can look at attributes such as the resource being accessed or the time of the request. The simplest example is a role that applies only during certain hours, or a temporary grant that expires automatically on a chosen date.

Privileged Access Manager gives people strong access only for a short, recorded time.

Standing access, meaning permissions that a person holds all day every day, is risky for the most powerful roles. Google’s overview describes Privileged Access Manager, often shortened to PAM, as letting principals request temporary, auditable access instead of holding standing permissions. Requests can require a written justification or approval from someone else.

sequenceDiagram
  participant E as Engineer
  participant P as Privileged Access Manager
  participant M as Approver
  participant R as Sensitive resource
  E->>P: Request temporary elevated access with a reason
  P->>M: Ask for approval
  M-->>P: Approve
  P-->>E: Grant access for limited time
  E->>R: Do the urgent task
  P->>P: Access expires and is logged
        

Give each identity the smallest access that lets it do its job, and keep trimming.

The principle of least privilege says every person and program should have only the permissions needed for its task, no more. It is simple to say and hard to keep, because access tends to grow over time: people change jobs, projects end, and quick fixes become permanent. Google’s governance guidance points to a tool called IAM recommender, part of Policy Intelligence, which finds unused roles and suggests removing or narrowing them. The guidance also describes using Policy Analyzer for periodic access certification, such as finding which principals can reach a given resource.

Managing people through groups keeps IAM policies short and understandable.

Google’s governance guidance recommends using Cloud Identity to manage users and groups, including federating identities with outside providers. It advises granting access to groups instead of individuals, keeping more than one group administrator, limiting who can manage a group, restricting membership to people inside your organization, and setting membership expiry so access ends automatically.

Audit logs are the record that lets you investigate and prove what happened.

Google Cloud records activity in audit logs. The governance guidance points to Admin Activity audit logs, which record IAM policy changes, service account creation, and key downloads, and to Policy Denied audit logs, which show blocked attempts. For some services, you can also enable data access logs to track reads and writes of data. Logs can be exported to BigQuery or another destination if you need to keep them beyond the default retention period. The guidance also advises reviewing impersonation events to see which user acted through a service account.

Most access errors can be solved by asking the same few questions in order.

When a request fails with a permission error, resist the urge to grant a powerful role. Work through the cause instead. Google also notes that the IAM programming interface is eventually consistent, meaning reads right after writes may return older data and changes can take time to take effect. A newly created service account, for example, might not be found immediately. So a brief wait is sometimes the right first step.

Teams with healthy IAM repeat a few simple habits and avoid a few common traps.

Patterns that work

Anti-patterns to avoid

IAM is powerful, and it works alongside other security controls rather than replacing them.

Related controls

flowchart LR
  ID["Identity: who are you?"] --> IAM["IAM: what may you do?"]
  IAM --> NET["Network and perimeter controls"]
  NET --> DATA["Data and encryption controls"]
  IAM --> LOG["Audit logs record everything"]
        

The big ideas are shared across clouds, though the names and structures differ.

Here is how IAM ideas appear in everyday projects.

If you remember nothing else, remember these habits.

Quick answers to questions beginners ask most.

Identity and Access Management. It decides who can do what on which Google Cloud resource by checking permissions before any action runs.

A permission is one allowed operation. A role is a bundle of permissions. You cannot grant permissions directly; you grant roles.

An authenticated identity that can be given access, such as a Google Account, a group, a service account, or a federated identity. Older material may call it a member.

Basic roles, which are broad and meant mainly for testing; predefined roles, managed by Google Cloud services for common jobs; and custom roles, which you create with chosen permissions.

A document attached to a resource that contains role bindings linking roles to principals. It was previously called an IAM policy.

Policies on organizations, folders, and projects pass down to the resources beneath them. The effective policy of a resource combines its own policy with all of its ancestors’ policies.

An identity for an application or virtual machine rather than a person, used so programs can call Google Cloud services with only the roles they need.

Avoid them where possible. Prefer attaching a service account to the workload or using workload identity federation, which reduces long-lived secrets.

An allow policy grants access through roles. A deny policy blocks specific permissions even if a principal holds a role that includes them.

Use conditional role bindings that expire, group membership with an end date, or Privileged Access Manager for just-in-time access with approval and logging.

Google notes the IAM interface is eventually consistent, so recent changes can take a short time to take effect. Wait briefly and retry before assuming the change failed.

I did not find a price for core IAM in the documentation I reviewed. Some related advanced products may be priced separately, so check Google’s pricing pages for the specific features you use.

IAM is Google Cloud’s authorization system. It answers one question for every request: may this principal perform this action on this resource? Access is built from principals, roles that bundle permissions, and resources, connected by allow policies that inherit down the hierarchy of organization, folders, projects, and resources. Service accounts and federation give programs and outside users identities of their own. Deny policies, principal access boundaries, conditions, and Privileged Access Manager add guardrails and temporary access. Good practice means groups instead of individuals, narrow predefined roles, grants at the lowest level, no unnecessary keys, regular reviews, and careful logging. Master these ideas and you will understand most of what protects every other Google Cloud service.