Google Cloud IAM: Identity and Access Management
—date: 2019-07-08 originally posted here
Identity & Access Management let the user manage access control/policies to the resources by defining who(identity) and what they can access(roles). Today we will talk about the Google Cloud Identity & Access Management and understand what it is and How to use it.
Policy in IAM is composed of the binding list which binds the Member Identity and Roles together to limit the access on google cloud resources.
Member can be of the following type
- Google Account: This can be any valid Google account with gmail.com or with any other domain name.
- Service Account: Account related to the application rather than an individual, you can have as many numbers of service account for the logical components of your application.
- Google Group: Google group are the collection of the different Google account and service account. Every group has a unique email id which can be used to identify members in the IAM policy. The benefit of group account is that if you want to change the permission of user you can simply move the user from one group to another group rather than changing the permission of the users.
- G Suited domain: Is the virtual group of all the account created in the organization Suite.
Roles on other hand is collection of permission which is mainly represented as .., for example pubsub.subscriptions.consume. Permission determines what type of operation can be performed on resources. Permission cannot be directly applied to resources instead you can assign roles which are a group of different permission.
In Google Cloud Platform Roles are of three kinds
- Primitive Roles
- Predefined Roles
- Custom Roles
Primitive Roles
These are of three types Owner, Editor and Viewer as the name suggest.
- Viewer has only access to view the resources and data.
- Editor has Viewer permission + permission to change/edit the resources.
- Owner has the permission of editor + permission to manage all resources and user.
Predefined Roles
These are the roles provides by Cloud IAM in addition to primitive roles which provide more granular level access to the resources and these primitive roles differ based on different resources in the cloud, you can check these roles over here
Custom Roles
Cloud IAM let the user define different custom roles if primitive and predefined roles do not fulfill their requirements. Though there is some pointer to remember while creating the custom roles. Custom roles can be defined on Organization and Project level but not on Folder level and custom roles should have an iam.roles.creator
So now the question is how these rules actually work as we know that policy is the binding list which binds the member and roles. These policies are connected to resources and are enforce access control when these resources are accessed.
Google Cloud Policy have a hierarchy Organization > Folder > Project > Resources, every resource has exactly one parent and inherit the policy from its parent. Any policy assign on the parent is applied to all its child's. Here is the diagram from Google Cloud IAM docs which show how this hierarchy looks.
Here an example from official docs how permission hierarchy works,
In the diagram above, topic_a is a Cloud Pub/Sub resource that lives under the project example-prod. If you grant the Editor role to micah@gmail.com for example-prod, and grant the Publisher role to song@gmail.com for topic_a, you effectively grant the Editor role for topic_a to micah@gmail.com and the Publisher role to song@gmail.com.
So here my effort to explain Google IAM policy in simple words, Hope you find it usefully. Please do share any feedback or any topic you think I should cover in this post. Till then Happy Clouding :)
Refernces: