What is Identity and Access Management in Google Cloud?

Identity and Access Management (IAM) is a way of classifying:

• Who: can be a person, group, or application.

• Can do what: special rights or actions.

• On what resource: GCPGoogle Cloud Platform service, i.e., GCSGoogle Cloud Storage, BigQuery, PubSub, etc.

For example, I could provide you the privilege or role of compute viewer. This role provides you with read-only access to enlist Compute Engine resources without reading the data stored on them.

Cloud IAMIdentity and Access Management is composed of different objects, as shown in the image below.

To better understand where these objects fit, let’s look at the Cloud IAM resource hierarchy.

Google Cloud Platform resources are arranged hierarchically, as shown below.

Explanation

1. The organization junction is the origin of the hierarchy.

2. Folders are the descendants of the organization.

3. Projects are the descendants of the folders, and the individual resources are the descendants of projects.

Cloud IAM authorizes you to set policies at all levels where a policy contains a set of roles and role members.

Hierarchy

Let’s go through each level from top to bottom, because resources inherit policies from their parent.

Organization

The organization resource represents your company. All resources inherit Cloud IAM roles granted at this level under organization.

Folder

The folder resource can represent your department, and all resources inherit Cloud IAM roles given at this level that the folder contains.

Projects

Projects represent a security barrier within your company. Services inside the corresponding project have a default level of security.

Resources

The IAM policy hierarchy always reflects the same route as the resource hierarchy. If you modify the resource hierarchy, the policy hierarchy will also change.

For example, moving a project to a different organization will update the project’s IAM policy to receive from the new organization’s IAM. Downward policies cannot restrict access granted at the origin level.

Suppose I allow you the editor role for Department X and the viewer role at the setup-box-de (as shown in the last image) project level. You will still have the editor role for that project.

Hence, it is best to follow the rule of least privilege. The regulation applies to identities, roles, and resources. Always select the smallest scope necessary for the task to reduce your risk exposure.