Private networking and Cloud Run (original) (raw)

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

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

• Basic networking
• Google CloudVirtual Private Cloud (VPC)networks

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 aShared VPC.
• You might have on-premises workloads or workloads on other clouds connected to this environment usingCloud VPNorCloud Interconnect.
• You might have enabled aVPC 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 resources are not associated with any particular VPC network by default. This page explains how to incorporate Cloud Run resources 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 resource only allows requests from your private network.

For example,receiving requests from VPC networksmight require different configuration thanreceiving requests from on-premises resources and other clouds.

Receive requests from other Cloud Run resources or App Engine

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

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

1. Configure the source resource 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 resource to route all traffic through the VPC network and enable Private Google Accesson the subnet associated with Direct VPC egress or the connector.
   • Set up Private Service Connector an internal Application Load Balancer to front your destination Cloud Run resource. 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_resource and configure DNSto 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 resources that have external IP addresses or useCloud NAT can directly access the internet and Google Cloud services such as Pub/Sub and Cloud Run. For other resources, there are a few options to enable the traffic path to Cloud Run:

• The most direct path is to enable Private Google Accesson the subnets that host your resources. When Private Google Access is enabled, resources on the subnets can access your Cloud Run resources at the default run.app URL. Traffic from your VPC network to Cloud Run stays in Google's network. In that case, the IP range for requests sent to the Cloud Run resource is0.0.0.0/32. This means that in request log entries, the remoteIpattribute of theHttpRequest will be 0.0.0.0.
• If you need your Cloud Run resource (together with other Google APIs) to be accessible through an internal IP address in your VPC network, consider creating aPrivate Service Connect endpointand configuring a private DNS zonefor run.app. With this configuration, resources in the VPC network can access Cloud Run resources at the default run.app URL through the Private Service Connect endpoint IP address.
• If you need load balancing capabilities and controls, consider using aninternal Application Load Balancer. With this approach, resources in the VPC network access your Cloud Run resources by using the URL associated with the internal Application Load Balancer.
• 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 the service by using Private Service Connect. Projects that need to consume the service can access it by using aPrivate Service Connect endpointor a Private Service Connect backend.

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

Special considerations for Shared VPC

When using the internal setting with Cloud Run ingress controlsto enforce that all traffic must come from your private network, Shared VPC traffic is only recognized as "internal" in the following situations:

• The Cloud Run resource is running in the Shared VPC host project.
• Shared VPC ingress: the Cloud Run resource is attached to a Shared VPC network. In this scenario, note the following considerations:
  • Only service revisions that have configuredDirect VPC egress or that have configured a Serverless VPC Access connectorto 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 by 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 resource from the Shared VPC network, redeploy without VPC network access, or with the resource 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 Controlsperimeter. To set up VPC Service Controls, seeUsing VPC Service Controls (VPC SC).

Special considerations for other VPC networks outside your project

When using the internal setting with Cloud Run ingress controlsto enforce that all traffic must come from your private network, traffic from other VPC networks 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.comas a restricted service, and Private Google Access is enabled for the source subnet.
• Your Cloud Run resource ispublishedas a managed service by using Private Service Connect (requires an internal Application Load Balancer), and it isaccessedfrom the other VPC network.

Peering with a VPC network that is outside of your project doesn't 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 BigQuery, Cloud Scheduler, Cloud Tasks, Dialogflow CX, 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 or App Engine 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 theReceive requests from other Cloud Run services or App Enginesection.
• If your chosen Google Cloud service is not able to access Cloud Run resources that have ingress set to internal, note that many services support authenticating to Cloud Run, such asPub/Sub(supports both internal and authentication),API Gateway, and Dialogflow CX(supports both internal and authentication). Depending on your security needs, it might be sufficient for the destination Cloud Run resource to require authentication instead of "internal" ingress.
• Requests from Google Cloud services not mentioned previously are not recognized as internal and cannot be received by Cloud Run resources that have ingress set to internal orinternal-and-cloud-load-balancing.

Receive requests from on-premises resources or other clouds

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

• Basic configuration: To have requests from on-premises resources and other clouds traverse your private network, configurePrivate Google Access for on-premises hosts.
• Make the Cloud Run resource accessible through an internal IP address: To call Cloud Run resources using an internal IP address, create aPrivate Service Connect endpoint to access Google APIs,configure a private DNS zonefor run.app, and configure your on-premises network to access the endpoint. With this configuration, on-premises hosts can access Cloud Run resources at the default run.app URL through the Private Service Connect endpoint IP address.
• With load balancing capabilities: If you need load balancing capabilities and controls, use aninternal Application Load Balancer. For information about accessing internal Application Load Balancer from on-premises networks, see Use Cloud VPN and Cloud Interconnect.
• 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 the service by using Private Service Connect(requires an internal Application Load Balancer). To access the service from on-premises hosts, create a Private Service Connect endpoint and configure the on-premises network to access the endpoint. For more information, seeAccess endpoints from hybrid networks. Alternatively, you can use a Private Service Connect backendwith a load balancer. For information about accessing load balancers from on-premises networks, see the documentation for the load balancer that you're using--for example, for internal Application Load Balancers, see Use Cloud VPN and Cloud Interconnect.

Require requests to come from your private network

To prevent incoming traffic (ingress) from external sources, you specify a restrictive ingress setting. The most restrictive ingress setting is internal. With ingress set tointernal, 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 resource, or enforce the use of your preferred ingress setting for all Cloud Run resources in your organization.

• To specify the ingress setting for each Cloud Run resource: SeeSetting ingress.
• To enforce a particular ingress setting for all Cloud Run resources in your project, folder, or organization: Configure the run.allowedIngress organization policy constraint. To learn how, seeCustomizing policies for list constraints.

Send requests to your private network

If your Cloud Run resource needs to access a resource on your private network, you 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 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 youregress setting is configured otherwise.

With requests routed using Direct VPC egress or connectors, responses return using the path that the request went through. Requests from your VPC network to Cloud Run are enabled by using other technologies and are not routed through Direct VPC egress or connectors, and responses to those requests are returned using the same path. To learn more about sending requests from your VPC network to Cloud Run, see 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 Connect to a Shared VPC network.
2. For other VPC networks, configure Direct VPC egress or a connector to connect to a VPC in your project.
   • Peered VPC networks: 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 VPC networks: For VPC networks outside of your project that are not part of the same Shared VPC environment or peered to your project VPC network, configurePrivate Service Connectafter setting up VPC network egress.

Send requests to other Cloud Run resources and Google Cloud services

Requests from one Cloud Run resource 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 resources with restrictive ingress settings, additional configuration is required. SeeReceive requests from other Cloud Run resources or App Engine.

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 do the following:

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 tosend requests to your VPC network.
3. Require that all requests go to your VPC network.

Require that all requests go to your VPC network

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

This is useful in the following situations:

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

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

• To specify the egress setting for individual Cloud Run resources: seeControl egress service traffic.
• To enforce a particular egress setting for all Cloud Run resources in your project, folder, or organization: configure the run.allowedVPCEgress organization policy constraint. To learn how, seeCustomizing policies for list constraints.

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.
  • To understand VPC Service Controls, seeOverview of VPC Service Controls.
  • To get started, see the Cloud Run guideUsing VPC Service Controls (VPC SC).
  • To understand costs, reviewpricing.
• Granular controls: To control access for traffic from a specific resource within your private network, such as a specific Cloud Run resource or Compute Engine virtual machine, use service accounts to control permissions and authentication.
  • To understand service accounts, seeWhat are service accounts?
  • To get started, see the Cloud Runauthentication guides.

What's next

To learn more about delivering low latency and high throughput using a direct network path, see Direct VPC egress with a VPC network.