This page describes the Google Cloud resource hierarchy and theresources that can be managed using Resource Manager.

The purpose of the Google Cloud resource hierarchy is two-fold:

• Provide a hierarchy of ownership, which binds the lifecycle of a resource toits immediate parent in the hierarchy.
• Provide attach points and inheritance for access control and organizationpolicies.

Metaphorically speaking, the Google Cloud resource hierarchy resembles thefile system found in traditional operating systems as a way of organizing andmanaging entities hierarchically. Generally, each resource has exactly oneparent. This hierarchical organization of resources enables you to set accesscontrol policies and configuration settings on a parent resource, and thepolicies and Identity and Access Management (IAM) settings are inherited by the childresources.

Google Cloud resource hierarchy in detail

Google Cloud resources are organized hierarchically. All resources exceptfor the highest resource in a hierarchy have exactly one parent.At the lowest level, service resources are the fundamental components thatmake up all Google Cloud services. Examples of service resources includeCompute Engine Virtual Machines (VMs), Pub/Sub topics, Cloud Storagebuckets, App Engine instances. All these lower level resources have projectresources as their parents, which represent the first groupingmechanism of the Google Cloud resource hierarchy.

All users, including free trial users, free tier users, and Google Workspace andCloud Identity customers, can create project resources.Users of theGoogle Cloud Free Program can onlycreate project resources and service resources within projects. Project resources canbe the top of their hierarchy, but only if created by a free trial user or freetier user. Google Workspace and Cloud Identity customershave access to additional features of the Google Cloud resource hierarchy,such as organization and folder resources. Learn more intheoverview of Cloud Identity.Project resources at the top of their hierarchy do not have parentresources, but they can be migrated into an organization resource once it hasbeen created for the domain. For more details about migrating project resources,seeMigrating project resources.

Google Workspace and Cloud Identity customers can create organizationresources. Each Google Workspace or Cloud Identity account is associatedwith one organization resource. When an organization resource exists,it is the top of the Google Cloud resource hierarchy, and all resourcesthat belong to an organization are grouped under the organization resource.This provides central visibility and control over every resource that belongs toan organization resource.

Folder resources are an additional, optional grouping mechanism betweenorganization resources and project resources. An organization resource isrequired as a prerequisite to use folders. Folder resources and their childproject resources are mapped under the organization resource.

The Google Cloud resource hierarchy, especially in its most complete formwhich includes an organization resource and folder resources, allows companiesto map their organization resource onto Google Cloud and provides logical attachmentpoints for access management policies (IAM) andorganization policies.Allow, deny, and organization policies are inherited through the hierarchy, andthe effective policy for each resource in the hierarchy is the result ofpolicies directly applied on the resource and policies inherited from itsancestors.

The following diagram represents an example Google Cloud resource hierarchy inits complete form:

The organization resource

Theorganization resourcerepresents an organization (for example, a company) and is the root node in theGoogle Cloud resource hierarchy when present. The organization resource isthe hierarchical ancestor of folder and project resources. The allow and denypolicies applied on the organization resource apply throughout the hierarchy onall resources in the organization.

Google Cloud users are not required to have an organization resource, butsome features of Resource Manager will not be usable without one. The organizationresource is closely associated with aGoogle Workspace orCloud Identityaccount. When a user with a Google Workspace or Cloud Identityaccount creates a Google Cloud project resource, an organization resourceis automatically provisioned for them.

A Google Workspace or Cloud Identity account can have exactly oneorganization resource provisioned with it. Once an organization resource iscreated for a domain, all new Google Cloud project resources created bymembers of the account domain will by default belong to the organizationresource. When a managed user creates a project resource, the requirement isthat it must be insome organization resource. If a user specifies anorganization resource and they have the right permissions, the project isassigned to that organization. Otherwise, it will default to the organizationresource the user is associated with. It is impossible for accounts associatedwith an organization resource to create project resources that aren't associatedwith an organization resource.

Link with Google Workspace or Cloud Identity accounts

For simplicity we will refer to Google Workspace meaning bothGoogle Workspace and Cloud Identity account.

The Google Workspace or Cloud Identity account represents acompany and is a prerequisite to have access to the organization resource. Inthe Google Cloud context, it provides identity management, recoverymechanism, ownership and lifecycle management. The following image shows the linkbetween the Google Workspace account, Cloud Identity, and theGoogle Cloud resource hierarchy.

The Google Workspace super admin is the individual responsible for domainownership verification and the contact in cases of recovery. For this reason,the Google Workspace super admin is granted the ability to assignIAM roles by default. The Google Workspace super admin'smain duty with respect to Google Cloud is to assign the OrganizationAdministrator IAM role to appropriate users in their domain. Thiswill create the separation between Google Workspace and Google Cloudadministration responsibilities that users typically seek.

Benefits of the organization resource

With an organization resource, project resources belong to your organizationinstead of the employee who created the project. This means that the projectresources are no longer deleted when an employee leaves the company; insteadthey will follow the organization resource's lifecycle on Google Cloud.

Furthermore, Organization Administrators have central control of all resources.They can view and manage all of your company's project resources. Thisenforcement means that there can no longer be shadow projects or rogue admins.

Also, you can grant roles at the organization level, which are inherited by allproject and folder resource under the organization resource. For example, youcan grant the Network Admin role to your networking team at the organizationlevel, allowing them to manage all the networks in all project resources in yourcompany, instead of granting them the role for all individual project resources.

An organization resource exposed by the Cloud Resource Manager API consists of thefollowing:

• An organization resource ID, which is a unique identifier for an organization.
• A display name, which is generated from the primary domain name inGoogle Workspace or Cloud Identity.
• The creation time of the organization resource.
• The last modified time of the organization resource.
• The owner of the organization resource. The owner is specified when creatingthe organization resource. It cannot be changed once it is set. It is theGoogle Workspace customer ID that is specified in theDirectory API.

The following code snippet shows the structure of an organization resource:

{  "creationTime": "2020-01-07T21:59:43.314Z",  "displayName": "my-organization",  "lifecycleState": "ACTIVE",  "name": "organizations/34739118321",  "owner": {    "directoryCustomerId": "C012ba234"  }}

The initial allow policy for a newly created organization resourcegrants the Project Creator and Billing Account Creator roles to the entireGoogle Workspace domain. This means users will be able to continuecreating project resources and billing accounts as they did before theorganization resource existed. No other resources are created when anorganization resource is created.

The folder resource

Folder resources optionally provide an additional grouping mechanismand isolation boundaries between projects. They can be seen as sub-organizationswithin the organization resource. Folder resources can be used to modeldifferent legal entities, departments, and teams within a company. For example,a first level of folder resources could be used to represent the maindepartments in your organization resource. Since folder resources can contain projectresources and other folders, each folder resource could then includeother sub-folders to represent different teams. Each team folder could containadditional sub-folders to represent different applications. For more detailsabout using folder resources, seeCreating and managing folder resources.

If folder resources exist in your organization resource and you have appropriateviewing permissions, you can view them from the Google Cloud console. For moredetailed instructions, seeViewing or listing folder and project resources.

Folder resources allow delegation of administration rights, so for example, eachhead of a department can be granted full ownership of all Google Cloudresources that belong to their departments. Similarly, access to resources canbe limited by folder resource, so users in one department can only access andcreate Google Cloud resources within that folder resource.

The following code snippet shows the structure of a folder resource:

{  "createTime": "2030-01-07T21:59:43.314Z",  "displayName": "Engineering",  "lifecycleState": "ACTIVE",  "name": "folders/634792535758",  "parent": "organizations/34739118321"}

Like organization and project resources, folder resources act as a policyinheritance point for allow, deny, and organization policies.IAM roles granted on a folder resource are automaticallyinherited by all project and folder resources included in that folder.

The project resource

The project resource is the base-level organizing entity. Organization andfolder resources may contain multiple projects. A project resource is requiredto use Google Cloud, and forms the basis for creating, enabling, and using allGoogle Cloud services, managing APIs, enabling billing, adding andremoving collaborators, and managing permissions.

All project resources consist of the following:

• Two identifiers:
  1. Project resource ID, which is a unique identifier for the projectresource.
  2. Project resource number, which is automatically assigned when you createthe project. It is read-only.
• One mutable display name.
• The lifecycle state of the project resource; for example, ACTIVE orDELETE_REQUESTED.
• A collection of labels that can be used for filtering projects.
• The time when the project resource was created.

The following code snippet shows the structure of a project resource:

{"createTime":"2020-01-07T21:59:43.314Z","lifecycleState":"ACTIVE","name":"my-project","parent":{"id":"634792535758","type":"folder"},"projectId":"my-project","labels":{"my-label":"prod"},"projectNumber":"464036093014"}

In order to interact with most Google Cloud resources, you must providethe identifying project resource information for every request. You can identifya project resource in either of two ways: a project resource ID, or a projectresource number (projectId andprojectNumber in the code snippet).

A project resource ID is the customized name you chose when you created theproject resource. If you activate an API that requires a project resource, youwill be directed to create a project resource or select a project resource usingits project resource ID. (Note that thename string, which is displayed in theUI, is not the same as the project resource ID.)

A project resourcenumber is automatically generated by Google Cloud. Both the projectresource ID and project resource number can be found on the dashboard of theproject resource in the Google Cloud console. For information on getting projectidentifiers and other management tasks for project resources seeCreating and managing project resources.

The initial IAM policy for the newly created project resourcegrants the owner role to the creator of the project.

Allow and deny policy inheritance

Google Cloud offersIAM, which lets youassign granular access to specific Google Cloud resources and prevents unwantedaccess to other resources. IAM lets you control who (users)has what access (roles) to whichresources by setting allow and denypolicies on the resources.

You can set allow and deny policies onorganization resources,folder resources, andproject resources. You can set allow policies on someservice resources as well.

Resources inherit the policies of the parent resource. If you set an allow ordeny policy at the organization level, it is inherited by all child resources.If you set an allow policy at the project level, it is inherited by all itschild resources.

The effective allow or deny policy for a resource is the union of the allow ordeny policy set on the resource and the allow or deny policy inherited from itsancestors. This inheritance is transitive. For more information, seePolicy evaluation.

For example, in the preceding resource hierarchy diagram, if you set an allowpolicy on the "Department Y" folder which grants the Compute EngineInstance Admin (roles/compute.instanceAdmin) role to bob@example.com, thenBob will have that role on "Development project," "Test project," and"Production project." If you assign alice@example.com the Compute EngineInstance Admin role on "Test project", she is only able to manageCompute Engine instances in that project.

Roles are always inherited. If you removed the Compute Engine InstanceAdmin (roles/compute.instanceAdmin) role from Bob on the "Test project", hewould inherit that role from the "Department Y" folder. You can use adeny policy to prevent principals from usinginherited permissions.

Allow and deny policies are inherited through the Google Cloud resourcehierarchy. If you change the resource hierarchy, the allow and deny policyhierarchy changes as well. For example, moving a project into an organizationresource will update the project's allow and deny policies to inherit from theorganization resource's allow and deny policies. Similarly, moving a projectresource from one folder resource to another will change the inheritedpermissions. Permissions that were inherited by the project resource from theoriginal parent resource will be lost when the project resource is moved to anew folder resource. Permissions set at the destination folder resource will beinherited by the project resource as it is moved.