# Google Cloud Platform's Identity Access Managing

Whether you're just starting out with GCP or a seasoned professional in need of an organized summary, this introduction caters to both audiences.


In the realm of cloud infrastructure, particularly in platforms like GCP, Identity and Access Management holds immense significance as a security control.

Given that almost every operation is executed through API calls - encompassing tasks like resource provisioning, de-provisioning, and manipulation - all it takes for an unauthorized entity to infiltrate your environment is an incorrect binding of permissions with identities or the exploitation of a compromised identity.

It is essential to carefully consider the permissions granted to access resources in your GCP Organization and ensure that only the necessary permissions are given for business operations.

In simpler terms, you should always maintain minimal privileges for all individuals and services. This article will explain the primary method used in GCP to manage resource permissions, making it a valuable read for beginners or experienced professionals seeking a structured overview.

The permission assignment in GCP is facilitated through a mechanism known as Role Based Access Control (RBAC). RBAC operates on the principle that permissions are allocated based on the functions that an identity is authorized to perform. To establish this connection, GCP employs Roles as permission documents and defines how they relate to an identity (or Principal) and a Scope - indicating at which level of the resource hierarchy these permissions are valid.

The diagram provided depicts the various components associated with GCP IAM and their interconnections for assigning permissions to resources. We will delve into these terms in detail.

Figure 1 showcases the representation of IAM-related objects in GCP. Given the significance of Scope in the GCP IAM framework, it is crucial to organize your Organization's resources appropriately. Hence, we will commence by examining the recommended structure for resources.

## **Organizational Structure of GCP Resources**
When you initiate your usage of GCP, an Organization resource is automatically established for users who possess a Google Workspace or Cloud Identity account.

This particular resource symbolizes the entity that owns it and functions as a container for Folders, Projects, and various resources that are arranged hierarchically. Such organization permits the effective management of diverse policies, among which IAM holds significant importance. Refer to Figure 2 for an illustration of the resource hierarchy within GCP's Organization resources.

The atomic container known as Projects is utilized for effectively managing resources in an application's deployment stages (e.g., development, testing, staging, production). These Projects also play a crucial role in billing since they maintain a direct 1-to-1 relationship with billing accounts. Drawing parallels to Azure's Resource Group and Subscription functionalities, Projects encompass both aspects seamlessly.

Whether situated directly under the organization resource or nested within Folders corresponding to the organizational structure, Projects offer versatility in organizing resources while accommodating sub-folder arrangements.

Properly organizing resources is crucial in the context of IAM, as permissions can be granted for individual resources or groups of resources at different levels such as organization, folder, or project (we will illustrate this later). Aligning your resource structure with your business greatly simplifies granting appropriate access.

Access may be granted to a range of different identities, as will be discussed in the next section.

## Personalities

**Google offers both Google Workspace and Cloud Identity, which are distinct yet interconnected solutions for businesses.**

[Google Cloud Platform](https://digitalbestacc.com/product/buy-google-cloud-accounts/) Identity serves as an Identity as a Service (IDaaS) solution that offers centralized management of users and groups. Essentially functioning as an identity provider (IdP), it enables the creation and administration of user and group objects, along with the ability to handle parameters such as security factors (MFA) and application access. It is worth mentioning that this service may be recognized by its alternative name, Google Workspace.

The management of users and groups is done in Google Cloud Identity, and the Domain identity can also be utilized to represent the entire user roster within a Google Cloud Identity instance.

* **Google Workspace users**

Within Google Workspace, you can oversee user entities for your organization. Each user is distinguished by their email address and is categorized into Organizational Units (OUs), which proves beneficial for implementing policies like MFA and application access.

It's important to note that OUs do not play a role in managing IAM access to Google Resources. Refer to Figure 3 for an illustration of a Google Cloud Identity user residing in an OU.

* **Google Communities**

The management of user access to GCP resources relies on Google Groups as the relevant mechanism. Initially created as a solution for mailing distribution lists, Google Groups have an associated email account that uniquely identifies them.

By assigning permissions to Google Groups, you grant access to all the identities within the group instead of managing individual user permissions separately.

It's worth mentioning that Google Groups can be nested and may contain other groups, which will inherit the assigned permissions. Furthermore, a Google Group can include service accounts, which we will discuss further in the next section.

* **Domains within the GCP Workspace**

In the context of GCP Workspace, it is important to note the presence of a familiar object known as the domain. Every Google Cloud Identity possesses a primary domain (e.g., @company name. com), which can be utilized to grant permissions for cloud resources to all users managed within the Google Cloud Identity instance.

There are two important points to consider: firstly, when permissions are assigned to the primary domain, it grants access to all users managed within that Cloud Identity instance, excluding the Google Groups stored there. The reasoning behind this is evident, as granting access to identities within the Google Groups could potentially expose external identities and pose a significant security risk.

Additionally, a Cloud Identity instance can have multiple secondary domains, up to 599 of them. It is important to note that the primary domain holds significance, while the actual domain of the users is not relevant.

To illustrate, if a secondary domain like @secondary.com exists in your Cloud Identity environment and your primary domain is @primary.com, granting access to @primary.com would automatically provide access to all users with the @secondary.com suffix managed within the Cloud Identity instance. The distinction in domains becomes insignificant when permissions are assigned. Now, let's shift our focus to identities managed within GCP itself.

* **Google Cloud Platform Service Accounts**

In GCP, service accounts function as proxy identities that facilitate the access of resources by other entities. This concept is similar to the role functionality in AWS.

A **[Google Cloud Account](https://digitalbestacc.com/product/buy-google-cloud-accounts/)** as a service is accessible to various identities including Google Cloud Identity users, personal Gmail accounts, service accounts from different organizations, Google Groups, and any other identity that has been granted permissions.

* **Unique Labels**

The final category of identity we should acknowledge consists of two distinct identifiers: all users and all authenticated users. These identifiers grant access to anyone connected to the internet and all service accounts, as well as users who have authenticated with a Google Account.

Consequently, utilizing either of these identifiers for a permission assignment renders that assignment accessible to the applicable resources by the public. It would be beneficial to provide an illustrative example at this point.

Numerous individuals mistakenly assume that these identifiers solely pertain to users within their specific Google Cloud Identity instance, but this is certainly not accurate. Therefore, it is crucial to exercise caution.

* **Roles**

Google created and managed these roles, known as Primitive Roles, which are legacy roles. They are highly permissive and apply to all resource types, resulting in a comprehensive list of permissions.

There are three Basic Roles - Viewer, Editor, and Owner.
When using them, it is crucial to exercise great care - it would be best to avoid using them completely if possible.

As previously mentioned, you may also want to consider replacing them in situations where they are automatically granted, such as with the default service account for the Compute Engine, which is automatically given the Editor Role on a project with enabled computing services.

Avoid assigning these roles to users who are not part of your Google Cloud Identity or service accounts outside your GCP organization. It is important to note that there are further risks associated with the permissions granted by these roles, which will be discussed in more detail in a future post. Stay tuned for more information!

## **The Process of Granting IAM Permissions in GCP**
To consolidate all these elements, let us now apply the principles we have reviewed - Identities, Roles, and Resource structures with varying scopes - and witness how permissions are practically authorized.

To authorize permission, you generate what is known as a binding - an object that establishes the connection between a Role (a set of permissions) that is granted to an identity (any of those we previously mapped) for a specific scope - either a resource or a container containing resources. These bindings are grouped within an IAM Policy document that exists on each scope. A binding comprises both the role itself and the members (identities) who can be granted this role.

Additionally, it can optionally incorporate conditions to restrict when and where this particular binding applies.

Figure 6 - Example of an IAM policy document, source: Google
External users, including personal Gmail accounts and service accounts of third parties, can easily create a binding just like users from your Google Cloud Identity instance or service accounts in your organization. Refer to Figure 8 for an example.

Therefore, it is important to pay close attention to this. Furthermore, managing external identities with access to resources in your organization becomes challenging as there is no native tool in GCP that consolidates them into a single display.

**Creating a binding for an internal identity**

Lastly, it is essential to keep in memory that according to the aforementioned explanation, bestowing a role on scope results in its inheritance by lower-level scopes encompassing containers and resources. This concept is visually depicted in Figure 9 through the diagram's representation of how the Compute Admin role extends to all compute resources within its corresponding scopes. Moreover, the basic Owner role applies to both compute and cloud functions resources.

The IAM blade within each scope showcases all bindings associated with it, either through direct assignment or inheritance from broader scopes. Figure 10 presents an example of this visualization for a GCP Project, demonstrating the role and principal involved.

Additionally, there is an inheritance column that distinctly identifies if the permission originates from a direct binding or if it is inherited from the project's association with another scope—specifically in this case, bindings established on the organization resource to which the project belongs.

### **Conclusion**
It is our sincere belief that this review has effectively illuminated the RBAC paradigm in GCP, ensuring a thorough comprehension for your benefit.

This post merely grazes the surface of this highly intricate and significant subject. To delve deeper, we encourage you to watch our recent webinar that delves into native tools available for mitigating IAM risks. Stay subscribed for updates on our forthcoming Google Cloud IAM posts.