Google Cloud Platform (GCP) Permissions Handling

By: Eyal Levy- CloudGuard, Research Team

Introduction

Managing access authorization for your cloud assets is a challenging task. Certainly, when dealing with multiple public/private resources, environments, services, providers, and users.

The GCP IAM service, which Google provides to each cloud account, is an Identity and Access Management system for central authentication and authorization management.

GCP IAM allows you to get control over Who has Which access rights and Where (on which resources). The scope of IAM access policies ranges from the global level, applying to each organization resource on the cloud, to particular cases, such as a single cloud resource.

In this blog post we cover the fundamentals of IAM in GCP, describing IAM key concepts (principals, roles, resources) and their application with the IAM allow policy. We will also highlight a few areas where having additional safeguards, like CloudGuard CSPM, can ensure the safety of your Google cloud accounts.

Who?

Before deciding whether to allow an action or not, you must authenticate the identity of the requester. In GCP, the requesting entity is called principal (former name is member, which is still in use in some GCP APIs).  A principal can be any of the following types:

• Google account / Google group
• Service account
• Google Workspace account / Cloud Identity domain
• All users / All authenticated users

A Google account is simply a registered, authenticated user (Google) account, such as a private Gmail account.

A Google Group can contain several Google user/service accounts, and is identified by a single email address, which allows assigning the same access rights to multiple entities.

Service accounts represent non-human users and are recommended whenever an application or code needs access to a cloud resource without the use of user credentials. The application/run-time code assumes the identity of the service account to call Google APIs.

Service accounts do not need passwords, as they use internally managed RSA key pairs for authentication. The private key is never exposed, and the key pair is rotated automatically every two weeks, making service accounts the preferred choice for securing app credentials.  However, most out-of-the-box (default) service accounts are created with extensively over-permissive access rights, and, therefore, must be either demoted or replaced, to adhere to the principle of least privilege (see below).

Service accounts, same as user and group accounts, are identified by a unique email address. For example, the email address identifying the default App Engine service account has the form:  project-id@appspot.gserviceaccount.com.

Google Workspace account / Cloud Identity domain represents a virtual group of all Google accounts within an organization. These organization accounts are associated with the organization’s internet domain name, such as example.com.

GCP allows several options to link, or federate, Google’s Cloud Identity service with an organization’s identity provider, enabling, among other things, enforcement of IAM policies for the entire organization. This also includes granting authorization rights that apply to all users in the domain (user@example.com).

Finally, the values allAuthenticatedUsers and allUsers are special identifiers used to represent the following identities:

• All Authenticated Users: Any service/user account on the Internet that has authenticated with a Google account.
• All Users: Anyone on the Internet.

For example, granting the Storage Object Viewer role permissions to the allUsers principal on a specific storage bucket makes that bucket’s resources public.  * Not all resources support any or both special identifiers.

Which (access) right?

Now that we have established (and authenticated) who is the requesting identity, let us have a look at how GCP manages users/services permissions using GCP roles.

A role in GCP is a collection of permissions defined with no regard to principals (identities) or resources.

The predefined role Storage Object Viewer

 

Since roles are a fundamental part of the GCP IAM authorization mechanism, and since overly permissive roles are automatically granted to default service accounts, understanding, monitoring, and configuring roles correctly is essential for achieving enterprise cloud security in Google Cloud.  GCP defines three types of roles:

Basic roles

Originally known as “primitive roles”, these three historical, pre-IAM roles hold thousands of permissions each:

 

 

Title	Role ID	Current # of permissions	Description
Viewer	roles/viewer	2627	View practically everything
Editor	roles/editor	5373	View and edit practically everything
Owner	roles/owner	5827	View, edit and manage practically everything (Superuser)

 

 

 

The Editor basic role is known as one of the GCP’s most dangerous configuration pitfalls:

• Editor (roles/editor) is automatically granted to some of the most important default service accounts, including the Compute Engine default service account and the App Engine default service account.
• The identity of these service accounts has a fixed format, making searching/finding them an easy task. The default Compute Engine service account has the form: < project-number-compute@developer.gserviceaccount.com >

                                                                                              Editor basic role

 

• The Editor’s massive permissions set limits potential attackers only by their imagination.

 

To follow the security principle of least privilege, Google suggests avoiding and replacing basic roles whenever possible by switching to predefined or custom roles.

Relevant CloudGuard CSPM rule: ●       GCP.IAM.12 – Avoid using pre-IAM basic (primitive) roles

 

 

 

Predefined roles

Google Cloud provides numerous predefined roles with granular access, tailored to specific service needs.  The IAM & Admin -> Role’s page on Google Cloud Console lists over 1000 predefined roles:

Clicking on a role opens the role details window:

 

The list of predefined roles and their corresponding permissions is located here.

Custom roles

If no predefined role meets your exact needs, GCP enables creating new, user-defined roles, to support any custom permissions list (which could be generated out of an existing role, or from scratch).

 

Where (on Which Resources)?

Google Cloud accounts can be either:

• A standalone project account that offers a limited resource hierarchy with the project at the top of the hierarchy and all its resources beneath it (the only available option for a free/trial GCP account).
• An organization account that provides a fully developed resource hierarchy, central management of all organization’s projects, and access to the Organization Policy service.

While this blog focuses on organization accounts, most of the following information also applies to standalone project accounts (inheritance and IAM policies).  Resources in GCP are hierarchical; every child node inherits the IAM policy of its parent(s), enabling structured and centralized authorization management.  The following are the resource types in the GCP hierarchy:

Organization > Folders > Projects > Resources

 

diagram source: Google

 

Organization

• The Organization is the root node in the Google Cloud resource hierarchy, and the only node having no parents.
• The Organization node is available for Google Workspace or Cloud Identity accounts associated with a domain (com).
• A single organization account can have only one organization node associated with one domain and one superuser (roles/owner). The identity of the superuser is specified when creating the organization node and cannot be changed.
• Any cloud resource created by any domain user (user@example.com) is created under the organization node.
  Any IAM access control policy applied to the organization resource applies to each resource in the entire hierarchy.

Folder

• The GCP folder resource enables logical grouping and categorizing of projects according to the organization structure, and represents different departments, teams, or products.
• A folder can contain any combination of subfolders and projects.
• The folder inherits the IAM policy from the organization node or from a parent folder. Each IAM policy set for a folder is inherited by all subfolders, projects, and resources under the folder.

Project

• The project resource is a basic organization entity that is required for using GCP services.
• Any allocated Google Cloud resource must belong to some project.
• Each project has its own settings, permissions, and other metadata describing the project’s specific application.

Resource

• At the lowest level of the GCP resource hierarchy model there are the base cloud resources (aka service resources). These resources can be Compute Engine VMs, GKE clusters, App Engine instances, Cloud Storage buckets and even service accounts (a service account is both a principal and a resource).
• Some service resources, including all examples mentioned above, can have an IAM policy of their own, making their effective permissions a combination of all parental IAM policies with the resource’s own IAM policy.

 

Now that we understand the Who? Which (rights)? and Where (on which resources)? it is time to bind them all together, using the GCP IAM policy.

“One (IAM) Policy to bind them”

The glue that connects all IAM elements is the Google Cloud IAM Policy.

The IAM Policy (also called allow policy) is a collection of statements that define access to cloud resources. It is where we grant a role to a principal on a specific resource.

An allow policy (IAM policy) in JSON format

In this example, there are two role bindings:

• The Storage Object Admin role is granted to:
  • one user (bob)
  • one service account (the App Engine default service account of the project my-app-project)
  • one Google group (admins@my-domain.com)
  • all users of the domain my-admins-domain.com

• The Storage Object Viewer role is granted to the user alice@my-domain.com

This allow policy can be applied to any level of resource hierarchy, that is, it could be set for the entire organization, a folder, a single project, or a specific cloud storage bucket.

A resource can be attached to a single allow policy only.

Check Point CloudGuard customers benefit from numerous GCP IAM compliance/best practices detection rules, for example: ●       GCP.IAM.03 – Ensure that multi-factor authentication is enabled for all non-service accounts ●       GCP.IAM.05 – Ensure that Service Account has no Admin privileges ●       GCP.IAM.07 – Ensure User-Managed/External Keys for Service Accounts Are Rotated Every 90 Days or Fewer ●       GCP.IAM.15 – Ensure permissions to impersonate a service account are not granted at project level

 

 

GCP is an evolving platform, that constantly adds, and updates features, for example, check out the preview of the Deny policy feature.  Google’s current best practices advise not to use legacy authorization mechanisms (Compute Instance access scopes, Cloud Storage bucket ACL), which clearly shows Google’s intention to set IAM as the only method for configuring access authorization in GCP.  Having additional safeguards, like CloudGuard CSPM, can ensure the safety of your Google cloud accounts.