Identity and Access Management in Cloud

This post focuses IAM on Google Cloud Platform only.

What is identity access management?

It is a way of identifying who can do what, on which resource. The who can be a person, group, or application. The what refers to specific privileges or actions and the resource could be any GCP service. For example, I could give you the privilege or role of compute viewer. This provides you with read-only access to get enlist Compute Engine resources without being able to read the data stored on them. Cloud IAM is composed of different objects as shown in the image below.

To get a better understanding of where these fit in, let's look at the Cloud IAM resource hierarchy. Google Cloud Platform resources are organized hierarchically as shown in this tree structure.

The organization node is the root node in this hierarchy. Folders are the children of the organization. Projects are the children of the folders, and the individual resources are the children of projects. Each resource has exactly one parent. Cloud IAM allows you to set policies at all of these levels. Where a policy contains a set of roles and role members.

Let's go through each of the levels from top to bottom because resources inherit policies from their parent.

• The Organization resource represents your company. Cloud IAM roles granted at this level are inherited by all resources under the organization.

• The folder resource could represent your department. Cloud IAM roles granted at this level are inherited by all resources that the folder contains.

• Projects represent a trust boundary within your company. Services within the same project have a default level of trust.

The Cloud IAM policy hierarchy always follows the same path as the GCP resource hierarchy, which means that if you change the resource hierarchy the policy hierarchy also changes. For example, moving a project into a different organization will update the projects Cloud IAM policy to inherit from the new organization's Cloud IAM policy.

Also, child policies cannot restrict access granted at the parent level. For example, if I grant you that editor role for department X and I grant you the viewer role at the Bookshelf(as shown in the last image) project level, you still have the editor role for that project.

Therefore, it is a best practice to follow the principle of least privilege. The principle applies to identities, roles, and resources. Always select the smallest scope that's necessary for the task in order to reduce your exposure to risk.

Hope you got a little bit idea about IAM policies now,
Happy Learning.

other reads

All you need to know about Python Lists

Kedar Kodgire ・ Apr 1 '20

#python #codenewbie #learning #productivity

Stuck at home, corona? Spend your time learning for free (15,000+ hours content).

Kedar Kodgire ・ Mar 27 '20

#beginners #tutorial #codenewbie #webdev

The Linux guide/cheatsheet/tutorial (Commands, Directories, etc)

Kedar Kodgire ・ Mar 21 '20

#linux #bash #computerscience

Three dots "..." in JS - Spread and Rest explained

Kedar Kodgire ・ Mar 25 '20

#webdev #codenewbie #javascript #learning

Keep in Touch

Don't forget to connect me on:

• LinkedIn
• twitter