1. IAM Overview

Organization & Folders

Cloud Identity

Workforce Identity Federation

Explore

Cloud IAM

Resource hierarchy

Service Accounts

IAM Best Practices

IAM lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. IAM lets you adopt the security principle of least privilege, which states that nobody should have more permissions than they actually need.

How IAM works?

With IAM, you manage access control by defining who (identity) has what access (role) for which resource.

The organizations, folders, and projects that you use to organize your resources are also resources.

In IAM, permission to access a resource isn't granted directly to the end user. Instead, permissions are grouped into roles, and roles are granted to authenticated principals. (In the past, IAM often referred to principals as members. Some APIs still use this term.)

An allow policy, also known as an IAM policy, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.

⁠

This model for access management has three main parts:

Principal. A principal represents an identity that can access a resource. Each principal has its own identifier.

Role. A role is a collection of permissions. Permissions determine what operations are allowed on a resource. When you grant a role to a principal, you grant all the permissions that the role contains.

Policy. The allow policy is a collection of role bindings that bind one or more principals to individual roles. When you want to define who (principal) has what type of access (role) on a resource, you create an allow policy and attach it to the resource.

Principals

In IAM, you grant access to principals, which represent an identity that can access a resource. In the context of access management, principals can be one of the following types:

⁠

Google Accounts⁠

⁠

Service accounts⁠

⁠

Google groups⁠

⁠

Google Workspace accounts⁠

⁠

Cloud Identity domains⁠

⁠

allAuthenticatedUsers⁠

⁠

allUsers⁠

⁠

One or more federated identities in a workforce identity pool⁠

⁠

One or more federated identities in a workload identity pool⁠

⁠

A set of Google Kubernetes Engine Pods⁠

⁠

Permissions

Permissions determine what operations are allowed on a resource. In the IAM world, permissions are represented in the form of service.resource.verb, for example, pubsub.subscriptions.consume.

Roles

A role is a collection of permissions. You cannot grant a permission to the user directly. Instead, you grant them a role. When you grant a role to a user, you grant them all the permissions that the role contains.

⁠

There are several kinds of roles in IAM:

Basic roles: Roles historically available in the Google Cloud console. These roles are Owner, Editor, and Viewer.

Caution: Basic roles include thousands of permissions across all Google Cloud services. In production environments, do not grant basic roles unless there is no alternative. Instead, grant the most limited predefined roles or custom roles that meet your needs.

Predefined roles: Roles that give finer-grained access control than the basic roles. For example, the predefined role Pub/Sub Publisher (roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.

Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don't meet your needs.

Allow policy

When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is allowed.

You can grant roles to users by creating an allow policy, which is a collection of statements that define who has what type of access. An allow policy is attached to a resource and is used to enforce access control whenever that resource is accessed.

⁠

An allow policy consists of a list of role bindings. A role binding binds a list of principals to a role.

role: The role you want to grant to the principal. role is specified in the form of roles/service.roleName. For example, Cloud Storage provides the roles roles/storage.objectAdmin, roles/storage.objectCreator, and roles/storage.objectViewer, among others.

members: A list of one or more principals as described in the

Concepts related to identity⁠

section in this document. Each principal type is identified with a prefix, such as a Google Account (user:), service account (serviceAccount:), Google group (group:), or a Google Workspace account or Cloud Identity domain (domain:). In the following example code snippet, the storage.objectAdmin role is granted to the following principals by using the appropriate prefix: user:my-user@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, and group:my-group@example.com. The objectViewer role is granted to user:my-user@example.com.

{

"bindings": [

{

"role": "roles/storage.objectAdmin",

"members": [

"user:my-user@example.com",

"serviceAccount:my-other-app@appspot.gserviceaccount.com",

"group:my-group@example.com"

]

{

"role": "roles/storage.objectViewer",

"members": [

"user:my-user@example.com"

]

}

]

}

Deny policies

Identity and Access Management (IAM)

deny policies⁠

let you set guardrails on access to Google Cloud resources. With deny policies, you can define deny rules that prevent certain principals from using certain permissions, regardless of the roles they're granted.