Cloud Identity And Access Management (IAM) in GCP
Hello Everyone
Welcome to CloudAffaire and this is Debjeet.
In this blog post, we will discuss identity and access management in GCP.
What Is Cloud IAM In GCP?
Cloud IAM lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. Cloud IAM lets you adopt the security principle of least privilege, where you grant only necessary permissions to access specific resources.
With Cloud IAM, you manage access control by defining who (identity) has what access (role) for which resource. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
In Cloud IAM, permission to access a resource isn’t granted directly to the end user. Instead, permissions are grouped into roles, and roles are granted to authenticated members. A Cloud IAM policy defines and enforces what roles are granted to which members, and this policy is attached to a resource. When an authenticated member attempts to access a resource, Cloud IAM checks the resource’s policy to determine whether the action is permitted.
Key Components Of Cloud IAM:
Member:
A member can be a Google Account (for end users), a service account (for apps and virtual machines), a Google group, or a G Suite or Cloud Identity domain that can access a resource. The identity of a member is an email address associated with a user, service account, or Google group; or a domain name associated with G Suite or Cloud Identity domains.
Members can be of the following types:
- Google Account: A Google Account represents a developer, an administrator, or any other person who interacts with Google Cloud. Any email address that’s associated with a Google Account can be an identity, including gmail.com or other domains.
- Service account: A service account is an account for an application instead of an individual end user. When you run code that’s hosted on Google Cloud, the code runs as the account you specify. You can create as many service accounts as needed to represent the different logical components of your application.
- Google group: A Google group is a named collection of Google Accounts and service accounts. Every Google group has a unique email address that’s associated with the group. You can find the email address that’s associated with a Google group by clicking About on the homepage of any Google group.
- G Suite domain: A G Suite domain represents a virtual group of all the Google Accounts that have been created in an organization’s G Suite account. G Suite domains represent your organization’s internet domain name (such as example.com), and when you add a user to your G Suite domain, a new Google Account is created for the user inside this virtual group (such as username@example.com).
- Cloud Identity domain: A Cloud Identity domain is like a G Suite domain because it represents a virtual group of all Google Accounts in an organization. However, Cloud Identity domain users don’t have access to G Suite applications and features.
- allAuthenticatedUsers: The value allAuthenticatedUsers is a special identifier that represents all service accounts and all users on the internet who have authenticated with a Google Account. This identifier includes accounts that aren’t connected to a G Suite or Cloud Identity domain, such as personal Gmail accounts.
- allUsers: The value allUsers is a special identifier that represents anyone who is on the internet, including authenticated and unauthenticated users.
Roles:
A role is a collection of permissions. You cannot grant a permission to the user directly. Instead, you grant them a role. When you grant a role to a user, you grant them all the permissions that the role contains.
Roles can be of the following types:
- Primitive roles: Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer. Avoid using these roles if possible, because they include a wide range of permissions across all Google Cloud services.
- Predefined roles: Roles that give finer-grained access control than the primitive roles. For example, the predefined role Pub/Sub Publisher (roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.
- Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.
Policy:
You can grant roles to users by creating a Cloud IAM policy, which is a collection of statements that define who has what type of access. A policy is attached to a resource and is used to enforce access control whenever that resource is accessed. A Cloud IAM policy is represented by the Cloud IAM Policy object. A Cloud IAM Policy object consists of a list of bindings. A Binding binds a list of members to a role.
You can set a Cloud IAM policy at any level in the resource hierarchy: the organization level, the folder level, the project level, or the resource level. Resources inherit the policies of the parent resource. If you set a policy at the organization level, it is automatically inherited by all its children projects, and if you set a policy at the project level, it’s inherited by all its child resources. The effective policy for a resource is the union of the policy set at that resource and the policy inherited from higher up in the hierarchy.
Resource:
If a user needs access to a specific Google Cloud resource, you can grant the user a role for that resource. Some examples of resources are projects, Compute Engine instances, and Cloud Storage buckets.
Some services support granting Cloud IAM permissions at a granularity finer than the project level. For example, you can grant the Storage Admin role (roles/storage.admin) to a user for a particular Cloud Storage bucket, or you can grant the Compute Instance Admin role (roles/compute.instanceAdmin) to a user for a specific Compute Engine instance.
In other cases, you can grant Cloud IAM permissions at the project level. The permissions are then inherited by all resources within that project. For example, to grant access to all Cloud Storage buckets in a project, grant access to the project instead of each individual bucket. Or to grant access to all Compute Engine instances in a project, grant access to the project rather than each individual instance.
Permissions:
Permissions determine what operations are allowed on a resource. In the Cloud IAM world, permissions are represented in the form of <service>.<resource>.<verb>, for example, pubsub.subscriptions.consume.
Permissions often correspond one-to-one with REST API methods. That is, each Google Cloud service has an associated set of permissions for each REST API method that it exposes. The caller of that method needs those permissions to call that method. For example, if you use Pub/Sub, and you need to call the topics.publish() method, you must have the pubsub.topics.publish permission for that topic.
You don’t grant permissions to users directly. Instead, you identify roles that contain the appropriate permissions, and then grant those roles to the user.
Hope you have enjoyed this article. In the next blog post, we will create our 1st Cloud IAM Role in GCP.
To get more details on cloud iam, please refer below GCP documentation.
https://cloud.google.com/iam/docs/