This section aims to provide a basic introduction to Google Cloud and the different concepts one needs to understand in order to work with it properly.
1.1 The GCP Resource Hierarchy
GCP resources are organized in a strict resource hierarchy.
Figure 1: The GCP resource hierarchy.
Projects are the core of this hierarchy, as every resource must belong to a project in order to be used. This means that you can not use GCP without creating at least one project.
Projects themselves can be organized further by using folders and organizations. An organization is most easily understood as one company, which has its own space within Google Cloud. It is the highest level on which access can be granted. Not all projects must belong to an organization, but for most companies it is highly advised. Within an organization, projects can belong to one folder. There can be multiple projects per folder and in turn multiple folders per organization. This hierarchy can be leveraged to set up permission inheritance. Users with a specific permission on a specific folder, by default have that permission on the projects and child-folders with that folder.
1.2 Identity and Access Management
Identity and Access Management (IAM) governs who can take what action on what resource. GCP uses a principle called Role Based Access Control (RBAC) to manage access. There are some important concepts to understand here:
- An IAM member is someone who wants to perform an action on a resource. This can be a user (optionally belonging to a group) or a service account (a form of identity mostly used to identify
- specific applications).
- A permission represents the permission to perform a specific action on a resource. An example could be “create a virtual machine instance”, which would be represented by the “compute.instances.create” permission.
- A role is a combination of permissions. For example the Compute Admin role will give you the permissions to create virtual machines, networks, etc. Roles have an identifier that looks like “roles/compute.admin”.
- A role binding is an assignment of a role to a specific IAM member, which means that that IAM member gets the permissions granted by that role. Roles can be assigned to users, service accounts and groups. The recommendation is always to work with groups where possible as individual users might leave the company, change teams, etc.
- A policy describes a series of role bindings. Policies can be defined at resource level, project level, folder level or organization level, depending on the type of resource. By default, GCP permissions are inherited down through the resource hierarchy. An organization level Viewer role will grant the user permission to view all projects in the organization. Although there are some ways to avoid the inheritance in specific cases, this is the default behavior of a policy.
1.3 Services
Google Cloud resources are grouped logically by services. A service is a specific API that can be used to manage resources within GCP. An example is the Compute service which is linked to compute.googleapis.com or Vertex AI linked to aiplatform.googleapis.com. In order to use resources within a service, that service must be enabled on the GCP project.
1.4 Locations, regions and zones
Services are consumed in specific locations. Which locations are available depends on the service being consumed. This can be an important consideration when it comes to local regulations (GDPR, HIPAA, …), but also has an impact on price.
The most general location is “global”, the global location indicates that there is no guarantee on where the service will be consumed.
However, most services can be configured to be used in a specific “re- gion”. A region is a geographic location, for instance Europe West or US East. These are large areas comprising of multiple “zones”, where
each zone corresponds to a datacenter in a specific location. Some services can also be used in a “multi-region” configuration where multiple regions are combined into one. Examples of multi-region config-
urations are US and EU.
