In the Google Cloud resource hierarchy, an organization is provisioned automatically and it is the top-level node above all other folders, projects, and resources. Any policies or restrictions set at the organization level will apply to the folders, projects, and resources that fall under it.
The hierarchy helps to manage access to resources, so there is no need to work with resource owners individually. For example, if a resource owner leaves an organization, the resource can be assigned to another user or team.
Following the Cloud Identity and organisation setup wizard introduced earlier in this chapter, you will be presented with various examples of how a resource hierarchy can be configured in the Hierarchy and access section:
Figure 12.10 – “Hierarchy and access” step of the “Cloud Identity and organization setup” checklist
Folders will help you to organize a hierarchy so it matches the structure of your company. For example, you can create folders for each department, nest additional folders for each team in a department, and set up permissions so that users can only access their team’s resources. The folder structure will also provide security isolation and separate workload types such as production and development.
Google Cloud projects, which are containers where you run workloads, can be attached directly to an organization or placed in folders or nested folders.
The following diagram presents an example of a simple resource hierarchy. Under Organization: example.com, there are two folders: test and production. In the test folder, there are two projects: test-1 and test-2, with various Google Cloud services. There is one project in the production folder: production, also with various Google Cloud services:
Figure 12.11 – Example of an organization hierarchy
IAM controls access to resources at different levels of a resource hierarchy. Permission to create, modify, or view a resource can have various attachment points – organization, folder, or project. For example, if a Compute Admin role was assigned to users at the organization level, it would be inherited by all projects. If a Compute Admin role was assigned at the folder level, as shown in Figure 12.11, where the Compute Admin role is assigned to users at the test folder level, it would be propagated only to projects test-1 and test-2 in the test folder. If a Compute Admin role was assigned to users at the project level (the production project in this example), it would be propagated only in this one project. In some cases, permissions can even be assigned to an individual resource in a project.
Note that a policy for a resource is a union of what is set on a resource directly and what is inherited as a project, a folder, and an organization policy. But if access is allowed higher in a hierarchy, it can’t be restricted at a lower level.