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 guide, you should have some familiarity with:

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 may have the following properties:

  • You may have a number of resources, such as VMs, sitting on one or more VPC networks.
  • These VMs may belong to many different projects, and they may be connected together with a Shared VPC.
  • You may have on-premises workloads or workloads on other clouds connected to this environment using Cloud VPN or Cloud Interconnect.
  • You may have enabled a VPC Service Controls perimeter to reduce the risk of data exfiltration.
  • You may have multiple such 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 guide explains how to incorporate Cloud Run services into your private network.

Receive requests from your private network

Receiving requests from your private network requires configuration based on:

  • Where the request is coming from
  • Whether or not the Cloud Run service is configured to only allow requests from your private network

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

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.
  3. If you need load balancing capabilities and controls, consider Internal HTTP(S) load balancer. With this approach, VPC resources access your Cloud Run services using the URL associated with the internal HTTP(S) 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 HTTP(S) load balancer and publish that using Private Service Connect. Projects wishing to consume the service can also access it using Private Service Connect.

Responses are returned 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 not recognized as "internal" except in the following situations:

  1. The Cloud Run service is running in the Shared VPC host project.
  2. You are using an internal HTTP(S) load balancer to proxy traffic.
  3. 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:

  1. VPC Service Controls is configured to allow the traffic, and Private Google Access is enabled for the source subnet.
  2. Your Cloud Run service is published as a managed service using Private Service Connect (requires Internal HTTP(S) load balancer) and it is accessed from the other VPC.

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.

Restrictive ingress settings

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

  • Requests from Eventarc, Pub/Sub, and Workflows in the same project or VPC Service Controls perimeter are recognized as "internal".
  • Requests from Cloud Run, App Engine, and Cloud Functions in the same project or VPC Service Controls perimeter are recognized as internal only with additional configuration. See the section Special considerations for traffic from other Cloud Run services, App Engine, and Cloud Functions.
  • 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 ingress=internal and authentication), API Gateway, and Dialogflow CX. Depending on your security needs, it may 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.

Special considerations for traffic from other Cloud Run services, App Engine, and Cloud Functions

If your Cloud Run service uses a restrictive ingress setting, then receiving requests from other Cloud Run services, App Engine, or Cloud Functions requires configuration:

  1. Configure your Cloud Run services, App Engine, or Cloud Functions to use Serverless VPC Access.
  2. Configure requests to Cloud Run to route through Serverless VPC Access. By default, only requests to destinations within a VPC network are routed using Serverless VPC Access. Since Cloud Run, App Engine, and Cloud Functions are not destinations within a VPC network, requests to these sources are not routed through Serverless VPC Access by default. To change this behavior, there are a couple of options:
    1. Configure all traffic to egress through Serverless VPC Access.
    2. Configure Private Service Connect or Internal HTTP(S) load balancer to front your destination Cloud Run services. With this configuration, you access Cloud Run using private IP addresses, so requests would be routed by Serverless VPC Access.
  3. Once the traffic is on the VPC network, make sure the VPC network is configured appropriately to further route that request to Cloud Run. See Receive requests from VPC networks.

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 Internal HTTP(S) load balancer (preview).
  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 Internal HTTP(S) 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 Serverless VPC Access. See Connecting to a VPC network (standard). Review pricing to understand costs.

When Serverless VPC Access is configured, then by default:

  1. All DNS queries are sent to the DNS server configured for the VPC that is associated with the connector.
  2. Requests to private IP addresses are routed through Serverless VPC Access to your VPC. Requests to public destinations continue to be routed directly to the internet, unless your egress setting is otherwise configured.

With requests routed using Serverless VPC Access, responses are returned using the path that the request went through. Requests from your VPC to Cloud Run are enabled using other technologies and are not routed through Serverless VPC Access, 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 Serverless VPC Access to connect to a VPC in your project.
    • Peered VPCs: To send to a VPC that is peered to a VPC that uses Serverless VPC Access, no additional configuration is required. However, the VMs in the subnet hosting Serverless VPC Access must be able to reach the target VPC.
    • Other VPCs: For VPCs 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 Serverless VPC Access.

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.

Limitations

For requests to Cloud Run services with restrictive ingress settings, additional configuration is required. See Special considerations for traffic from other Cloud Run services, App Engine, and Cloud Functions.

Send requests to on-premises resources and other clouds

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

  1. Make sure your VPC 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" Serverless VPC Access egress setting. You can specify the egress setting for each Cloud Run service that uses Serverless VPC Access, 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 situations such as the following:

  1. If you want to set up a static outbound IP address for your Cloud Run service.
  2. If 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 increases bandwidth use on your Serverless VPC Access connector and may increase costs accordingly. Serverless VPC Access connectors automatically scale out when traffic increases, but do not 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.