By: Eyal Levy- CloudGuard, Research Team 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. 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: 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 ([email protected]). Finally, the values allAuthenticatedUsers and allUsers are special identifiers used to represent the following identities:
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. 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:
The Editor basic role is known as one of the GCP’s most dangerous configuration pitfalls:
To follow the security principle of least privilege, Google suggests avoiding and replacing basic roles whenever possible by switching to predefined or custom 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:
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
Folder
Project
Resource
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:
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. How does the resources hierarchy control how IAM policies are inherited?IAM policy inheritance
Resources inherit the policies of the parent resource. If you set a policy at the organization level, it is inherited by all its child folder and project resources, and if you set a policy at the project level, it is inherited by all its child resources.
Can IAM policies that are implemented higher in the resource hierarchy?Can IAM policies that are implemented higher in the resource hierarchy take away access that is granted by lower-level policies? No. Policies implemented at a higher level in the hierarchy can't take away access that's granted at lower level.
Which basic permissions allows you to change access permissions on resources in Google Cloud?To control access to resources, Google Cloud requires that accounts making API requests have appropriate IAM roles. IAM roles include permissions that allow users to perform specific actions on Google Cloud resources.
At what level in the Google Cloud resource hierarchy is billing set up?According to Architecting with Google Kubernetes Engine: Foundations Week 1 Introduction to Google Cloud, configuring the billing account is possible at the folder level. However, according to Overview of Cloud Billing concepts, it should be at the project level.
|