Using Cloud Build in a private network

This page explains how to configure commonly-used private network setups to use with private pools. For an overview of private pools, see Private pools overview.

Defining the default network settings

When you create a private pool, by default you're set up to use the Virtual Private Cloud network in which the private pools reside. Use the default VPC network if:

  • You want builds to access the public internet.
  • You want configurable machine types and sizes, static internal IP ranges, or one of the other features of private pools.
  • You are not looking for builds to access resources within your private VPC network.

For instructions on connecting to the default network, see Creating a private pool.

Defining a static internal IP range

In some cases, you may need to have a defined static IP range for your private pool, such as when calling a service that allowlists calls from a defined IP range. With private pools, when setting up a private connection between your VPC network and the private pool's VPC network, you can create allocated IP address ranges with a defined CIDR range of IPs that your private pools will run on. You can also specify a smaller CIDR range within an allocated IP address range that a private pool will use.

Running in a VPC network

To use Cloud Build with resources in a private network behind a firewall, such as in a VPC network, you can create a private connection between the private pool and your managed VPC network. This enables the private pool to access resources in your private network such as source repositories, artifact repositories, databases, secrets instances, and runtimes.

Running in a shared VPC network

If you're using a shared VPC network, the project where you're creating the private pool must be attached to the host project that contains the shared VPC network. For instructions on attaching a project, see Provisioning a shared VPC network.

Connecting to resources in another peered VPC network or shared VPC network

Organizations often adopt a shared VPC (host project) to centralize networking and Identity and Access Management across all the projects. This allows internal IP addresses to be used for Google-managed services like private GKE clusters and private Cloud SQL. These Google-managed services are also peered into a customer-owned shared VPC network. The issue with this setup is that private pools are not able to communicate with the Google-managed services due to the lack of transitive peering. Transitive peering is only an issue when multiple networks are connected to one another via VPC peering. If one of the connections is changed to use a VPN (or interconnect) instead of VPC peering, then the networks can establish connectivity. For instructions on this network setup, see Accessing private Google Kubernetes Engine clusters with Cloud Build private pools.

Running in a specific region

You can create a private pool in one of the supported regions. You can store any built container images and artifacts in Artifact Registry repositories and Cloud Storage buckets in specified regions.

Deploying to private GKE clusters

Private GKE clusters can have a public or private endpoint for the control plane.

To deploy to a private GKE cluster with a public endpoint, you can create your private pool in the default network with access to the public internet and define a static internal IP range for your pool to allow list for access to the cluster.

To deploy to private GKE clusters with a private endpoint, you can follow the steps described in Accessing private Google Kubernetes Engine clusters with Cloud Build private pools. Alternatively, once peered into your VPC, you can run a network proxy on the cluster as described in Creating private GKE clusters with network proxies.

Using with VPC Service Controls

VPC Service Controls is a Google Cloud feature that allows you to set up a secure perimeter to guard against data exfiltration. For instructions on using VPC Service Controls with private pools to add additional security to your builds, see Using VPC Service Controls.

Removing public IPs on private pools

You can remove public IPs on private pools by setting egressOption field in the private pool config file to NO_PUBLIC_EGRESS. However, keep in mind that removing public IPs will restrict your private pool from accessing resources in the public internet.

Restricting egress to the public internet

There are few ways to restrict egress from private pools to the public internet:

Enforcing the usage of private pools

Cloud Build provides a constraints/cloudbuild.allowedWorkerPools organization policy constraint that you can enforce to mandate the builds in your organization to not use the default pool and only use the private pool. For instructions on using this feature, see Setting up organization policy constraints.

Using with private Cloud DNS zones

You can share a private Cloud DNS zone to use with private pools. For instructions, see Sharing a private zone.

Running behind a NAT

Although you can control the IP range of your private pool in your VPC, the external IP addresses (if enabled) cannot be controlled. If you need to access a resource from a reserved IP, create a proxy VM and route traffic through it by completing steps in Access external resource from a static source IP address using Cloud Build.

What's next