Google Identity and Access Management (IAM)

Google Identity and Access Management (IAM)

This blog talks about the Identity and Access Management System offered by Google, and its various features.

With cloud computing’s popularity increasing day by day, there’s a lot more data on the cloud. Resources that were traditionally stored in on-premise systems, have now moved to the cloud. However, when data is moved to the cloud, it is imperative to have control over who can access it. It is for this reason that having an Identity and Access Management service is necessary for any cloud service provider.

What Is IAM?

Google Identity and Access Management is a web service that gives cloud administrators the authority to decide who can take a particular action on a particular resource. In simple words, IAM lets one decide who (Identity) has what role (Access) to which resource.


Before proceeding further, let’s have a look into a few terms that are commonly associated with Google Identity and Access Management.


Let’s start with the Identity part of IAM. Every access and permission in IAM is given to a member. A member in Google IAM can be either an individual or a group.
Individual members are of two types – Google Account and Service Account. The main difference between the two is that while Google Account is any user with an email address, a Service Account is an account for an application. The identity of the member in both these cases is the email address associated with the said user.

Groups can also be members IAM members. The three types of groups in IAM are Google Group, G-Suite domain, and Cloud Identity Domain. Similar to individual members, Google Group is identified by an associated email address. In contrast, the other two group members are identified by the domain name associated with them.

Service Accounts

As mentioned above, service accounts are one of the types of individual members that IAM can have. Service Accounts differ from regular Google Accounts due to the fact that they’re not used by any person. A service account is a special kind of account that is used for applications or VM instances. It is used by these entities to make API calls on their behalf. There is no limit on the number of service accounts that can be created.

Service accounts are used to carry out server-to-server interactions in a project, without availing the user credentials. There are three types of Service Accounts:

  1. User-Created
  2. Built-In
  3. Google API

By default, all projects come with a Compute Engine Service Account, which has Editor permissions; and a GCP API Service Account. Each service has a scope, which is used to determine if the authenticated identity is authorized for the task. For example, in the image below, Application A has a read_only scope, while Application B has a read_write scope. This ensures they both get only the necessary permissions.

Service Account Scope


An organization is the root node for all Google Cloud resources. Organizations can have two roles in IAM- Organization Admin, and Project Creator. While the former has control over all cloud resources, the latter has command over who can create new projects in the organization. The Organization Admin defines all higher-level policies and assigns them to various roles. Only select users are given the Organization Admin role. This job is done by the Workspace Super Admin.

IAM Organization

Granting Access

Now we come to the Access part of IAM. Arguably one of the most important aspects of IAM is granting access to various resources. This can be done in two ways.

The first is the standard way of directly giving access. However, this practice is not followed in the IAM environment, as it affects the efficiency and security of the whole system.
The second way, and the one followed by IAM, is to grant access by assigning roles.  This way involves making roles that may contain permissions regarding one or more resources. These roles are then assigned to select members.


A role in IAM is an entity that defines a set of permissions, which are to be granted to select users. There are three types of roles in Google IAM.

Types of Roles

1. Primitive Roles

Also called Basic roles, these roles were there since before the introduction of IAM. They offer a fixed, coarse-grained level of access to GCP resources. Primitive roles are applicable across all Google Cloud services in a project. There are three primitive roles:

  1. Owner
  2. Editor
  3. Viewer

Basic Roles

2. Predefined Roles

Predefined roles were introduced with IAM to grant more fine-grained access control as compared to the Basic roles. These roles are only applicable to a particular service in a project. Any given predefined role can be granted to a resource type or a type above it. Multiple roles can be assigned to a single user as well. There are thousands of predefined roles in Google IAM.


3. Custom Roles

One of the more interesting parts of IAM is the ability to create your own custom roles. The user-created role can have one or more permissions associated with it. They can be created by combining existing Cloud IAM permissions. Custom roles are fully user-managed and have no involvement from Google’s side.

For the creation and management of custom roles, GCP provides a UI and an API. The only pre-requisite for creating a custom role is that one must have an Admin role themself. It can be either roles/iam.roleAdmin or roles/iam.organization.RoleAdmin, depending on whether the one creating the custom roles is an individual or an organization.

Custom Roles

Policies and Resources

A policy is an object that defines the permissions of a member or a resource. A resource here is an object within a service. Just one policy may be attached to a resource.

A policy in Google IAM consists of a list of bindings. These bindings bind a list of members to a role. Both policies and resources work on a hierarchical principle. The Organization node is the root node of this hierarchy. Folders come under the organization, followed by Projects. Individual resources (services) come under specific projects. Each resource has exactly one parent, although one project may have multiple descendants, ie. resources.

Policy hierarchy

An IAM policy can be set at any level in this hierarchy. Once specified, it is applicable to the concerned level, as well as those under it. The effective policy for any level is the combination of the policy set at that level, plus the ones inherited from higher classes. While the higher levels have a direct impact on the policies for lower levels, the reverse isn’t true. Child policies have no effect on access granted at a higher level.

Google IAM Features

Google’s Identity and Access Management offers a number of features to improve the user experience. Some of these are:

  • Single interface
    One access control interface for all IAM services
  • Fine-grained control
    Can grant access at resource level granularity if needed
  • Automatic recommendations
    Recommender detects resources having more permissions than required
  • Context-aware access
    Control access to resources based on various attributes
  • Flexible roles
    Option of Custom Roles expands the possible number of roles exponentially
  • Variety of input options
    IAM policies can be created & managed through Console or CLI
  • Audit trail
    A full audit trail is provided without additional cost

Best Practices

While IAM offers a lot of features to make the handling of cloud resources easier and more secure, there are a few things that need to be kept in mind while using it. The foremost among these being the Principle of Least Privilege (PLOP).
As we saw above, child policies can’t affect parent policies, but access or restrictions set at a higher level will apply for all levels below it. It is for this reason that it’s recommended that one give the minimum possible permissions, and at the smallest scope needed. For instance, if a person needs view-only access to a resource, it would not be very wise to grant editor permissions to them.
Some of the other practices that should be followed are listed as follows:

  • Mirror policy hierarchy structure to organization structure
  • Use projects to group resources that will be used together
  • Use labels to annotate, group, and filter resources
  • Audit the membership and ownership of groups used in policies, and the policies themselves for compliance


  1. Does IAM incur additional charges?
    No, all IAM services are bundled with Google Cloud Platform, free of cost.
  2. Which services are supported by IAM?
    All of Google Cloud Platform’s services- be it App Engine, Compute Engine, BigQuery- are supported by IAM.
  3. Are the policies set permanently?
    No, IAM policies can be edited as and when required from the Console or CLI.

Related References

Next Task For You

If you are also interested and want to know more about the Google Cloud Professional Cloud Engineer certification, register for our Free Class.

The post Google Identity and Access Management (IAM) appeared first on Cloud Training Program.

Go to Source of this post
Author Of this post: Ayoosh Q
Title Of post: Google Identity and Access Management (IAM)
Author Link: {authorlink}