Google Cloud IAM: Introduction

30 September 2021

What is Cloud IAM?

Google Cloud Identity & Access Management (IAM) is a web service which gives the cloud administrators an authority to decide “Who can do What on Which resources”.

Who – This part defines a member who accesses the resources in Google Cloud. Accesses and permissions in IAM are given to a member. It can be an individual, or a group.

Individual members are of following types

• Google Account – Google Account can be any user having an email address,
• Service Account – Service Account is an account for an application. It is a special type of a Google account which is representing a non-human user who needs to authenticate and be authorized for accessing data in Google APIs.

Groups can also be the members of IAM. There are three types of groups in IAM:

• Google Group
• G-Suite domain
• Cloud Identity Domain

What – This part defines a role to be granted to the member to access the resources.

There are following type of roles:

• Basic/Primitive Roles:
  • This includes the Owner, Editor and Viewer role. When these roles are assigned on the Project, they allow access to everything inside that project.
• Predefined Roles
  • This provides granular access for a specific Google Cloud service. Like: Compute Admin, Storage Object Viewer, etc.
• Custom Roles
  • This provides the facility to assign the different permissions as a bundle. Here, we are not assigning the permissions directly to the member. Instead, the role is getting created with the set of necessary permissions and that role will be assigned to the member.

Which – This part will include all the available Google Cloud resources.

Features:

• IAM can map the job functions into groups and roles.
• With the IAM roles, users only get access to what is needed to get the job done.
• It allows you to grant access to cloud resources from project-levels to fine-grained levels access.
• IAM enables you to set policies at the following levels in the resource hierarchy:
  • Organization level
    • The organization resource will represent your company.
    • IAM roles granted to this level are inherited by all the resources available under the organization.
  • Folder level
    • Folders contain projects/other folders/combinations of both.
    • Roles which are granted to this level are inherited by the projects, or other folders that are contained in the parent folder.
  • Project level
    • Projects are the level using which the resources can be accessed.
    • IAM roles granted to this level are inherited by all the resources within the project.
  • Resource level
    • This level grants certain users permission to a single resource within the project.

Best Practices

While the IAM offers many features to handle the cloud resources in an easier and more secured way, there are some terms that need to be considered while using it. The Principle of Least Privilege (PLOP) is the most important of these.

In the IAM, child policies can not be affected by parent policies. However, access/restrictions set at a higher level will get applied to all levels below it. Due to this, it is recommended that one give the minimum possible permissions and at the smallest scope needed. For example, if a person is required to have view-only access to a resource, it would not be very good if you grant editor permissions to them.

Some of the other practices that needs to be followed are listed as follows:

• • Use projects to group resources which will get used together
  • Use of labels can be helpful to annotate, group, and filter resources
  • Enforce the least privileges all times.
  • In order to decide how to use a service account, you can use the following flow-chart which will guide you for your decision-making process.

• For production workloads, it is the best practice if you use user-managed service accounts instead of the default service accounts.

🔊 Listen