Private networking and Cloud Run

This page discusses configuration options for including Cloud Run services in your private network.

To get the most out of this content, you should have some familiarity with the following concepts:

To secure network traffic for their services and applications, many organizations use a private network on Google Cloud with perimeter controls to prevent data exfiltration. Your private network might have the following properties:

  • You might have a number of resources, such as VMs, sitting on one or more VPC networks.
  • These VMs might belong to many different projects, and they might be connected together with a Shared VPC.
  • You might have on-premises workloads or workloads on other clouds connected to this environment using Cloud VPN or Cloud Interconnect.
  • You might have enabled a VPC Service Controls perimeter to reduce the risk of data exfiltration.
  • You might have multiple private networks, one for each of several different environments, such as one for production, one for staging, and one for development.

Unlike VMs, Cloud Run services are not associated with any particular VPC network by default. This page explains how to incorporate Cloud Run services into your private network.

Serverless networking narrative

To explore a range of common enterprise configurations for public and private networking, read our Serverless networking narrative.

This starting point introduces the following basic-to-advanced Cloud Run scenarios:

  • Safely deploy a "Hello, World!" app that uses a custom domain
  • Develop enterprise applications and microservices
  • Access databases and file systems publicly or privately
  • Connect with SaaS providers
  • Apply security controls

See the list of corresponding Terraform modules.

Receive requests from your private network

Receiving requests from your private network requires configuration based on the following conditions:

  • Where the request comes from.
  • Whether the Cloud Run service only allows requests from your private network.

For example, receiving requests from VPC networks might require different configuration than receiving requests from on-premises resources and other clouds.

Receive requests from other Cloud Run services, App Engine, and Cloud Run functions

When your destination Cloud Run service receives traffic from other Cloud Run services, App Engine, or Cloud Run functions, and uses the "internal" or "internal and load balancing" ingress setting, then the traffic must use the VPC network to be considered internal.

To receive requests from other Cloud Run services, App Engine, or Cloud Run functions, perform the following steps:

  1. Configure the source service to use either Direct VPC egress or a connector.

  2. Make sure traffic to Cloud Run routes through the VPC network by using one of the following options:

    • Configure the source service to send all traffic through the VPC network and enable Private Google Access on the subnet associated with Direct VPC egress or the connector.
    • Set up Private Service Connect or an internal Application Load Balancer to front your destination Cloud Run service. With this configuration, you access Cloud Run by using internal IP addresses, so requests are routed through the VPC network.
    • Enable Private Google Access on the subnet associated with the source service and configure DNS to resolve run.app URLs to the private.googleapis.com (199.36.153.8/30) or restricted.googleapis.com (199.36.153.4/30) ranges. Requests to these ranges are routed through the VPC network.

Receive requests from VPC networks

By default, only VPC resources that have public IP addresses or use Cloud NAT can directly access the internet and Google Cloud services such as Pub/Sub and Cloud Run. For other VPC resources, there are a few options to enable the traffic path to Cloud Run:

  1. The most direct path is to enable Private Google Access on the subnets hosting your VPC resources. Once enabled, resources on the subnets can access your Cloud Run services at the default run.app URL. Traffic from your VPC to Cloud Run stays in Google's network. In that case, the IP range for requests sent to the Cloud Run service is 0.0.0.0/32. This means that in request log entries, the remoteIp attribute of the HttpRequest will be 0.0.0.0.
  2. If you need your Cloud Run service (together with other Google APIs) to be exposed as an internal IP address in your VPC network, consider Private Service Connect. Once enabled, VPC resources can access your Cloud Run services at the default run.app URL using the internal IP address.
  3. If you need load balancing capabilities and controls, consider using an internal Application Load Balancer. With this approach, VPC resources access your Cloud Run services by using the URL associated with the internal Application Load Balancer.
  4. If you want to expose your service to internal clients as a managed service and be able to control which projects can access it, you can host it with an internal Application Load Balancer and publish that by using Private Service Connect. Projects that need to consume the service can also access it by using Private Service Connect.

Responses are returned by using the same path that the request went through.

Special considerations for Shared VPC

If you are using Cloud Run ingress controls to enforce that all traffic must come from your private network (using the internal setting), then note that Shared VPC traffic is only recognized as "internal" in the following situations:

  • The Cloud Run service is running in the Shared VPC host project.

  • Shared VPC ingress: The Cloud Run service is attached to a Shared VPC network. In this scenario, note the following considerations:

    • Only service revisions that have configured Direct VPC egress or that have configured a Serverless VPC Access connector to send traffic to the Shared VPC network will also accept traffic from that same Shared VPC network.

    • Requests use different paths based on the traffic direction. Requests sent from Cloud Run to the Shared VPC network are routed via Direct VPC egress or the connector. However, requests sent from the Shared VPC network to Cloud Run use the standard ingress path.

    • To detach a Cloud Run service from the Shared VPC network, redeploy without VPC network access, or with the service configured to send traffic to a different VPC network.

  • You are using an internal Application Load Balancer to proxy traffic.

  • You have placed the Shared VPC host and all service projects inside the same VPC Service Controls perimeter. To set up VPC Service Controls, see Using VPC Service Controls (VPC SC).

Special considerations for other VPCs outside your project

If you are using Cloud Run ingress controls to enforce that all traffic must come from your private network (using the internal setting), then note that traffic from other VPCs outside your project is not recognized as "internal" except in the following situations:

  • VPC Service Controls is configured to allow the traffic with run.googleapis.com as a restricted service, and Private Google Access is enabled for the source subnet.
  • Your Cloud Run service is published as a managed service by using Private Service Connect (requires an internal Application Load Balancer), and it is accessed from the other VPC network.

Peering a VPC outside your project does not allow traffic to be recognized as "internal".

Receive requests from other Google Cloud services

Requests to Cloud Run from Google Cloud services such as Pub/Sub stay within Google's network.

There are a few special considerations if you have configured Cloud Run ingress controls to only allow "internal" traffic:

  • Requests from Cloud Scheduler, Cloud Tasks, Eventarc, Pub/Sub, synthetic monitors (including uptime checks), and Workflows in the same project or VPC Service Controls perimeter are recognized as "internal."
  • Requests from Cloud Run, App Engine, and Cloud Run functions that are sent from within the same project or VPC Service Controls perimeter all require additional configuration before they are recognized as "internal". For details, see the Receive requests from other Cloud Run services, App Engine, and Cloud Run functions section.
  • If your chosen Google Cloud service is not able to access Cloud Run services that have ingress set to internal, note that many support authenticating to Cloud Run, such as Pub/Sub (supports both internal and authentication), API Gateway, and Dialogflow CX. Depending on your security needs, it might be sufficient for the destination Cloud Run service to require authentication instead of "internal" ingress.
  • Requests from Google Cloud services not mentioned above are not recognized as internal and cannot be received by Cloud Run services that have ingress set to internal or internal-and-cloud-load-balancing.

Receive requests from on-prem or other clouds

There are multiple ways to privately receive requests from on-premises resources and other clouds.

  1. Basic configuration: To have requests from on-premises resources and other clouds traverse your private network, configure Private Google Access for on-premises hosts.
  2. Expose the Cloud Run service with an internal IP address: To call Cloud Run services using an internal IP address, configure Private Service Connect for on-premises hosts. Adding Private Service Connect for on-premises hosts allows you to expose your Cloud Run service to your VPC network as an internal IP address. Private Service Connect incurs costs.
  3. With load balancing capabilities: If you need load balancing capabilities and controls, use an internal Application Load Balancer.
  4. Across administrative boundaries: If you want to expose your service to internal clients as a managed service and be able to control which projects can access it, you can publish it using Private Service Connect. To consume it, see Using Private Service Connect from on-premises hosts (requires an internal Application Load Balancer).

Require requests to come from your private network

To prevent incoming traffic (ingress) from external sources, you can specify a restrictive ingress setting. The most restrictive ingress setting is internal. With ingress set to internal, your service only allows requests from your project, Shared VPC networks your project is attached to, and your VPC Service Controls perimeter. There are some limitations with this setting depending on where the requests come from. To learn about these limitations and how to navigate them, see the section Receive requests from your private network.

You can specify the ingress setting for each Cloud Run service, or enforce the use of your preferred ingress setting for all Cloud Run services in your organization.

  • To specify the ingress setting for each service: See Setting ingress.
  • To enforce a particular ingress setting for all Cloud Run services in your project, folder, or organization: Configure the run.allowedIngress organization policy constraint. To learn how, see Customizing policies for list constraints.

Send requests to your private network

If your Cloud Run service needs to access a resource on your private network, you can configure a path for private requests to your network. The configuration depends on the final destination of the request.

Send requests to your VPC network

To send requests to a VPC network, you must configure Direct VPC egress or a Serverless VPC Access connector. Compare Direct VPC egress and VPC connectors. Review pricing to understand costs.

When Direct VPC egress or Serverless VPC Access connectors are configured, the following considerations apply by default:

  • All DNS queries are sent to the DNS server configured for the VPC network associated with your VPC network egress setup.

  • Requests to internal IP addresses are routed to the VPC network by using either Direct VPC egress or a connector. Requests to public destinations continue to be routed directly to the internet, unless your egress setting is configured otherwise.

With requests routed using Direct VPC egress or Serverless VPC Access connectors, responses are returned using the path that the request went through. Requests from your VPC to Cloud Run are enabled by using other technologies and are not routed through Serverless VPC Access or Direct VPC egress, and responses to those requests are returned using the same path. To learn more about sending requests from your VPC to Cloud Run, see the section Receive requests from VPC networks.

Sending requests to a VPC network outside of your project

To send requests to a VPC network outside of your project:

  1. For Shared VPC users, see Connecting to a Shared VPC network.
  2. For other VPCs, configure Direct VPC egress or a Serverless VPC Access connector to connect to a VPC in your project.
    • Peered VPCs: To send to a VPC that is peered to a VPC that uses VPC network egress, no additional configuration is required. However, the VMs in the subnet hosting VPC network egress must be able to reach the target VPC network.
    • Other VPCs: For VPC networks outside of your project that are not part of the same Shared VPC environment or peered to your project VPC, configure Private Service Connect after setting up VPC network egress.

Send requests to other Cloud Run services and Google Cloud services

Requests from one Cloud Run service to another or to other Google Cloud services stay within Google's internal network and are subject to VPC Service Controls.

For requests to Cloud Run services with restrictive ingress settings, additional configuration is required. See Receive requests from other Cloud Run services, App Engine, and Cloud Run functions.

Send requests to on-premises resources and other clouds

To send requests to on-premises resources and other clouds through your private network, you must:

  1. Make sure your VPC network is configured to privately route your traffic to the destination, such as through a VPN tunnel.
  2. Configure your service to send requests to your VPC network.
  3. Then require all requests to go to your VPC network.

Require all requests to go to your VPC network

To require all requests from your Cloud Run service to go to your VPC network, specify the "all-traffic" VPC network egress setting. You can specify the egress setting for each Cloud Run service that uses VPC network egress, or you can enforce the use of your preferred egress setting for all Cloud Run services in your project, folder, or organization.

This is useful in the following situations:

  1. You want to set up a static outbound IP address for your Cloud Run service.
  2. You want to apply firewall rules for all egress from a Cloud Run service.
  3. You want to send requests to on-premises resources and other clouds through your private network.

If your Cloud Run service makes requests to final destinations outside of your VPC network, requiring all requests to go to your VPC network increases bandwidth use on your Serverless VPC Access connector (if configured) and might increase costs accordingly. Serverless VPC Access connectors automatically scale out when traffic increases, but don't scale in if traffic decreases. Review pricing to understand costs.

Additional controls

  • Perimeter controls: To reduce the risk of data exfiltration for a group of resources, place them within a context-aware perimeter using VPC Service Controls.
  • Granular controls: To control access for traffic from a specific resource within your private network, such as a specific Cloud Run service or Compute Engine virtual machine, use service accounts to control permissions and authentication.

What's next

If you use Terraform, Terraform sample code is available for setting up Cloud Run services in a private network.