Deploy the blueprint

Prerequisites before deploying the foundation pipeline resources

Complete the following steps before you deploy the foundation pipeline:

• Create a Cloud Identity account and verify domain ownership .
• Apply for an invoiced billing account with your Google Cloud sales team or create a self-service billing account .
• Enforce security best practices for administrator accounts.
• Verify and reconcile issues with consumer user accounts .
• Configure your external identity provider as source of truth for synchronizing user accounts and SSO.
• Provision the groups for access control that are required to run the blueprint.
• Determine the network topology that you will use.
• Decide your source code management tool. The instructions for terraform-example-foundation are written to a Git repository that is hosted in Cloud Source Repositories.
• Decide your CI/CD automation tools. The terraform-example-foundation provides different sets of directions for different automation tools.

To connect to an an existing on-premises environment, prepare the following:

• Plan your IP address allocation based on the number and size of ranges that are required by the blueprint.
• Order your Dedicated Interconnect connections.

Steps to deploy the terraform-example-foundation from GitHub

Follow the README directions for each stage to deploy the terraform-example-foundation from GitHub:

• Stage 0-bootstrap to create a foundation pipeline.

  If using a self-service billing account, you must request additional project quota before proceeding to the next stage.

• Stage 1-org to configure organization-level resources.
• Stage 2-environments to create environments.
• Stage either 3-networks-dual-svpc or 3-networks-hub-and-spoke to create networking resources in your preferred topology.
• Stage 4-projects to create an infrastructure pipeline.
• Optionally, stage 5-app-infra for sample usage of the infrastructure pipeline.

Additional steps after IaC deployment

After you deploy the Terraform code, complete the following:

• Complete the on-premises configuration changes .
• Activate Security Command Center Premium .
• Export Cloud Billing data to BigQuery .
• Sign up for a Cloud Customer Care plan .
• Enable Access Transparency logs.
• Share data from Cloud Identity with Google Cloud .
• Apply the administrative controls for Cloud Identity which aren't automated by the IaC deployment.
• Assess which of the additional administrative controls for customers with sensitive workloads are appropriate for your use case.
• Review operation best practices and plan how to connect your existing operations and capabilities to the foundation resources.

Folder

fldr- environment

environment is a description of the folder-level resources within the Google Cloud organization. For example, bootstrap , common , production , nonproduction , development , or network .

For example: fldr-production

Project ID

prj- environmentcode - description - randomid

• environmentcode is a short form of the environment field (one of b , c , p , n , d , or net ). Shared VPC host projects use the environmentcode of the associated environment. Projects for networking resources that are shared across environments, like the interconnect project, use the net environment code.
• description is additional information about the project. You can use short, human-readable abbreviations.
• randomid is a randomized suffix to prevent collisions for resource names that must be globally unique and to mitigate against attackers guessing resource names. The blueprint automatically adds a random four-character alphanumeric identifier.

For example: prj-c-logging-a1b2

VPC network

vpc- environmentcode - vpctype

• environmentcode is a short form of the environment field (one of b , c , p , n , d , or net ).
• vpctype is one of svpc , float , or peer .

For example: vpc-p-svpc

Subnet

sn- environmentcode - vpctype - region {- description }

• environmentcode is a short form of the environment field (one of b , c , p , n , d , or net ).
• vpctype is one of svpc , float , or peer .
• region is any valid Google Cloud region that the resource is located in. We recommend removing hyphens and using an abbreviated form of some regions and directions to avoid hitting character limits. For example, au (Australia), na (North America), sa (South America), eu (Europe), se (southeast), or ne (northeast).
• description is additional information about the subnet. You can use short, human-readable abbreviations.

For example: sn-p-svpc-uswest1

Firewall policies

fw- firewalltype - scope - environmentcode {- description }

• firewalltype is hierarchical or network .
• scope is global or the Google Cloud region that the resource is located in. We recommend removing hyphens and using an abbreviated form of some regions and directions to avoid reaching character limits. For example, au (Australia), na (North America), sa (South America), eu (Europe), se (southeast), or ne (northeast).
• environmentcode is a short form of the environment field (one of b , c , p , n , d , or net ) that owns the policy resource.
• description is additional information about the hierarchical firewall policy. You can use short, human-readable abbreviations.

For example:

fw-hierarchical-global-c-01

fw-network-uswest1-p-svpc

Cloud Router

cr- environmentcode - vpctype - region {- description }

• environmentcode is a short form of the environment field (one of b , c , p , n , d , or net ).
• vpctype is one of svpc , float , or peer .
• region is any valid Google Cloud region that the resource is located in. We recommend removing hyphens and using an abbreviated form of some regions and directions to avoid reaching character limits. For example, au (Australia), na (North America), sa (South America), eu (Europe), se (southeast), or ne (northeast).
• description is additional information about the Cloud Router. You can use short, human-readable abbreviations.

For example: cr-p-svpc-useast1-cr1

Cloud Interconnect connection

ic- dc - colo

• dc is the name of your data center to which a Cloud Interconnect is connected.
• colo is the colocation facility name that the Cloud Interconnect from the on-premises data center is peered with.

For example: ic-mydatacenter-lgazone1

Cloud Interconnect VLAN attachment

vl- dc - colo - environmentcode - vpctype - region {- description}

• dc is the name of your data center to which a Cloud Interconnect is connected.
• colo is the colocation facility name that the Cloud Interconnect from the on-premises data center is peered with.
• environmentcode is a short form of the environment field (one of b , c , p , n , d , or net ).
• vpctype is one of svpc , float , or peer .
• region is any valid Google Cloud region that the resource is located in. We recommend removing hyphens and using an abbreviated form of some regions and directions to avoid reaching character limits. For example, au (Australia), na (North America), sa (South America), eu (Europe), se (southeast), or ne (northeast).
• description is additional information about the VLAN. You can use short, human-readable abbreviations.

For example: vl-mydatacenter-lgazone1-p-svpc-useast1-cr1

Group

grp-gcp- description @example.com

Where description is additional information about the group. You can use short, human-readable abbreviations.

For example: grp-gcp-billingadmin@example.com

Custom role

rl- description

Where description is additional information about the role. You can use short, human-readable abbreviations.

For example: rl-customcomputeadmin

Service account

sa- description @ projectid .iam.gserviceaccount.com

Where:

• description is additional information about the service account. You can use short, human-readable abbreviations.
• projectid is the globally unique project identifier.

For example: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Storage bucket

bkt- projectid - description

Where:

• projectid is the globally unique project identifier.
• description is additional information about the storage bucket. You can use short, human-readable abbreviations.

For example: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Organization:The blueprint uses a single organization as the root node for all resources.

Decide a resource hierarchy for your Google Cloud landing zone introduces scenarios in which you might prefer multiple organizations, such as the following:

• Your organization includes sub-companies that are likely to be sold in the future or that run as completely separate entities.
• You want to experiment in a sandbox environment with no connectivity to your existing organization.

Folder structure:The blueprint has a folder structure that divides workloads into production, non-production and development folders at the top layer.

Decide a resource hierarchy for your Google Cloud landing zone introduces other approaches for structuring folders based on how you want to manage resources and inherit policies, such as:

• Folders based on application environments
• Folders based on regional entities or subsidiaries
• Folders based on accountability framework

Organization policies:The blueprint enforces all organization policy constraints at the organization node.

You might have different security policies or ways of working for different parts of the business. In this scenario, enforce organization policy constraints at a lower node in the resource hierarchy. Review the complete list of organization policy constraints that help meet your requirements.

Deployment pipeline tooling:The blueprint uses Cloud Build to run the automation pipeline.

You might prefer other products for your deployment pipeline, such as Terraform Enterprise , GitLab Runners , GitHub Actions , or Jenkins . The blueprint includes alternative directions for each product.

Code repository for deployment:The blueprint uses Cloud Source Repositories as the managed private Git repository.

Use your preferred version control system for managing code repositories, such as GitLab , GitHub , or Bitbucket .

If you use a private repository that is hosted in your on-premises environment, configure a private network path from your repository to your Google Cloud environment.

Identity provider:The blueprint assumes an on-premises Active Directory and federates identities to Cloud Identity using Google Cloud Directory Sync.

If you already use Google Workspace, you can use the Google identities that are already managed in Google Workspace.

If you don't have an existing identity provider, you might create and manage user identities directly in Cloud Identity.

If you have an existing identity provider, such as Okta , Ping , or Azure Entra ID , you might manage user accounts in your existing identity provider and synchronize to Cloud Identity.

If you have data sovereignty or compliance requirements that prevent you from using Cloud Identity, and if you don't require managed Google user identities for other Google services such as Google Ads or Google Marketing Platform, then you might prefer workforce identity federation . In this scenario, be aware of limitations with supported services .

Multiple regions:The blueprint deploys regional resources into two different Google Cloud regions to help enable workload design with high availability and disaster recovery requirements in mind.

If you have end users in more geographical locations, you might configure more Google Cloud regions to create resources closer to the end user with less latency.

If you have data sovereignty constraints or your availability needs can be met in a single region, you might configure only one Google Cloud region.

IP address allocation:The blueprint provides a set of IP address ranges.

You might need to change the specific IP address ranges that are used based on the IP address availability in your existing hybrid environment. If you modify the IP address ranges, use the blueprint as guidance for the number and size of ranges required, and review the valid IP address ranges for Google Cloud .

Hybrid networking:The blueprint uses Dedicated Interconnect across multiple physical sites and Google Cloud regions for maximum bandwidth and availability.

Depending on your requirements for cost, bandwidth, and reliability requirements, you might configure Partner Interconnect or Cloud VPN instead.

If you need to start deploying resources with private connectivity before a Dedicated Interconnect can be completed, you might start with Cloud VPN and change to using Dedicated Interconnect later.

If you don't have an existing on-premises environment, you might not need hybrid networking at all.

VPC Service Controls perimeter:The blueprint recommends a single perimeter which includes all service projects for your Shared VPC topology.

You might have a use case that requires multiple perimeters for an organization or you might decide not to use VPC Service Controls at all.

For information, see decide how to mitigate data exfiltration through Google APIs .

Secret Manager:The blueprint deploys a project for using Secret Manager in the common folder for organization-wide secrets, and a project in each environment folder for environment-specific secrets.

If you have a single team who is responsible for managing and auditing sensitive secrets across the organization, you might prefer to use only a single project for managing access to secrets.

If you let workload teams manage their own secrets, you might not use a centralized project for managing access to secrets, and instead let teams use their own instances of Secret Manager in workload projects.

Cloud KMS:The blueprint deploys a project for using Cloud KMS in the common folder for organization-wide keys, and a project for each environment folder for keys in each environment.

If you have a single team who is responsible for managing and auditing encryption keys across the organization, you might prefer to use only a single project for managing access to keys. A centralized approach can help meet compliance requirements like PCI key custodians.

If you let workload teams manage their own keys, you might not use a centralized project for managing access to keys, and instead let teams use their own instances of Cloud KMS in workload projects.

Aggregated log sinks:The blueprint configures a set of log sinks at the organization node so that a central security team can review audit logs from across the entire organization.

You might have different teams who are responsible for auditing different parts of the business, and these teams might require different logs to do their jobs. In this scenario, design multiple aggregated sinks at the appropriate folders and projects and create filters so that each team receives only the necessary logs, or design log views for granular access control to a common log bucket.

Granularity of infrastructure pipelines:The blueprint uses a model where each business unit has a separate infrastructure pipeline to manage their workload projects.

You might prefer a single infrastructure pipeline that is managed by a central team if you have a central team who is responsible for deploying all projects and infrastructure. This central team can accept pull requests from workload teams to review and approve before project creation, or the team can create the pull request themselves in response to a ticketed system.

You might prefer more granular pipelines if individual workload teams have the ability to customize their own pipelines and you want to design more granular privileged service accounts for the pipelines.

SIEM exports:The blueprint manages all security findings in Security Command Center.

Decide whether you will export security findings from Security Command Center to tools such as Google Security Operations or your existing SIEM, or whether teams will use the console to view and manage security findings. You might configure multiple exports with unique filters for different teams with different scopes and responsibilities.