The root node for managing resources in Google Cloud is the organization. The Google Cloud organization provides a resource hierarchy that provides an ownership structure for resources and attachment points for organization policies and access controls. The resource hierarchy consists of folders, projects, and resources, and it defines the structure and use of Google Cloud services within an organization.
Resources lower in the hierarchy inherit policies such as IAM allow policies and organization policies. All access permissions are denied by default, until you apply allow policies directly to a resource or the resource inherits the allow policies from a higher level in the resource hierarchy.
The following diagram shows the folders and projects that are deployed by the blueprint.
The following sections describe the folders and projects in the diagram.
Folders
The blueprint uses folders to group projects based on their environment. This logical grouping is used to apply configurations like allow policies and organization policies at the folder level and then all resources within the folder inherit the policies. The following table describes the folders that are part of the blueprint.
| Folder | Description |
|---|---|
bootstrap |
Contains the projects that are used to deploy foundation components. |
common |
Contains projects with resources that are shared by all environments. |
production |
Contains projects with production resources. |
nonproduction |
Contains a copy of the production environment to let you test workloads before you promote them to production. |
development |
Contains the cloud resources that are used for development. |
networking |
Contains the networking resources that are shared by all environments. |
Projects
The blueprint uses projects to group individual resources based on their functionality and intended boundaries for access control. This following table describes the projects that are included in the blueprint.
| Folder | Project | Description |
|---|---|---|
bootstrap |
prj-b-cicd |
Contains the deployment pipeline that's used to build out the foundation components of the organization. For more information, see deployment methodology. |
prj-b-seed |
Contains the Terraform state of your infrastructure and the Terraform service account that is required to run the pipeline. For more information, see deployment methodology. | |
common |
prj-c-secrets |
Contains organization-level secrets. For more information, see store application credentials with Secret Manager. |
prj-c-logging |
Contains the aggregated log sources for audit logs. For more information, see centralized logging for security and audit. | |
prj-c-scc |
Contains resources to help configure Security Command Center alerting and other custom security monitoring. For more information, see threat monitoring with Security Command Center. | |
prj-c-billing-export |
Contains a BigQuery dataset with the organization's billing exports. For more information, see allocate costs between internal cost centers. | |
prj-c-infra-pipeline |
Contains an infrastructure pipeline for deploying resources like VMs and databases to be used by workloads. For more information, see pipeline layers. | |
prj-c-kms |
Contains organization-level encryption keys. For more information, see manage encryption keys. | |
networking |
prj-net-{env}-shared-base |
Contains the host project for a Shared VPC network for workloads that don't require VPC Service Controls. For more information, see network topology. |
prj-net-{env}-shared-restricted |
Contains the host project for a Shared VPC network for workloads that do require VPC Service Controls. For more information, see network topology. | |
prj-net-interconnect |
Contains the Cloud Interconnect connections that provide connectivity between your on-premises environment and Google Cloud. For more information, see hybrid connectivity. | |
prj-net-dns-hub |
Contains resources for a central point of communication between your on-premises DNS system and Cloud DNS. For more information, see centralized DNS setup. | |
prj-{env}-secrets |
Contains folder-level secrets. For more information, see store and audit application credentials with Secret Manager. | |
prj-{env}-kms |
Contains folder-level encryption keys. For more information, see manage encryption keys. | |
| application projects | Contains various projects in which you create resources for applications. For more information, see project deployment patterns and pipeline layers. |
Governance for resource ownership
We recommend that you apply labels consistently to your projects to assist with governance and cost allocation. The following table describes the project labels that are added to each project for governance in the blueprint.
| Label | Description |
|---|---|
application |
The human-readable name of the application or workload that is associated with the project. |
businesscode |
A short code that describes which business unit owns the
project. The code shared is used for common projects
that are not explicitly tied to a business unit. |
billingcode |
A code that's used to provide chargeback information. |
primarycontact |
The username of the primary contact that is responsible for the project. Because project labels can't include special characters such as the ampersand (@), it is set to the username without the @example.com suffix. |
secondarycontact |
The username of the secondary secondary contact that is responsible for the project. Because project labels can't include special characters such as @, set only the username without the @example.com suffix. |
environment |
A value that identifies the type of environment, such as
bootstrap, common, production,
non-production,development, or network. |
envcode |
A value that identifies the type of environment, shortened to
b, c, p, n,
d, or net. |
vpc |
The ID of the VPC network that this project is expected to use. |
Google might occasionally send important notifications such as account suspensions or updates to product terms. The blueprint uses Essential Contacts to send those notifications to the groups that you configure during deployment. Essential Contacts is configured at the organization node and inherited by all projects in the organization. We recommend that you review these groups and ensure that emails are monitored reliably.
Essential Contacts is used for a different purpose than the
primarycontact and secondarycontact fields that are configured in project
labels. The contacts in project labels are intended for internal governance. For
example, if you identify non-compliant resources in a workload project and need
to contact the owners, you could use the primarycontact field to find the
person or team responsible for that workload.
What's next
- Read about networking (next document in this series).