Configure network settings

Cloud Run functions network settings enable you to control network ingress and egress to and from individual functions. For example, you can use network settings for the following use cases:

• Secure your functions by implementing network-based access control.
• Make a function's egress traffic adhere to firewall, DNS, and routing rules associated with your VPC network.
• Associate a function's egress traffic with a static IP address.

For more details about use cases, see the Example use cases section.

Ingress settings

Ingress settings control whether resources outside of your Google Cloud project or VPC Service Controls service perimeter can invoke a function.

To be subject to a VPC Service Controls perimeter's policy, a resource must belong to the service to be restricted. For Cloud Run functions, the restricted service is Cloud Run Admin API.

Configure ingress settings

To restrict resources from outside of your project or perimeter, specify one of the following ingress setting values:

• Allow all traffic: Default. All inbound requests to the function are allowed, from both the internet and resources within the same project.

• Allow internal traffic only: Only traffic from Cloud Scheduler, Cloud Tasks, Eventarc, synthetic monitors (including uptime checks), Workflows, BigQuery, and VPC networks in the same project or VPC Service Controls perimeter is allowed. All other requests are denied with a 404 error.

  For requests from a Shared VPC, note the following considerations:

  • Traffic is considered internal if the function is deployed in the Shared VPC host project.
  • Traffic is considered internal if the Shared VPC host and all service projects are placed inside the same VPC Service Controls perimeter.
  • Traffic to a function is considered internal if the function is connected to the same Shared VPC network.
  • All other traffic from Shared VPC networks is denied.

• Allow internal traffic and traffic from Cloud Load Balancing: Traffic from Cloud Scheduler, Cloud Tasks, Eventarc, synthetic monitors (including uptime checks), Workflows, BigQuery, and VPC networks in the same project or VPC Service Controls perimeter is allowed. Traffic from Cloud Load Balancing is allowed.

You can specify ingress settings when you deploy or update your function by using the Google Cloud console, Google Cloud CLI, or Terraform:

  gcloud functions deploy FUNCTION_NAME 

  --trigger-http 

  --ingress-settings INGRESS_SETTINGS 

  FLAGS...
  

If you use Google Cloud Armor with Cloud Load Balancing, you can create security policies that filter traffic-based conditions such as an incoming request's IP address, IP range, region code, or request headers. For more information, see Google Cloud Armor security policy overview.

Egress settings

Egress settings control the routing of outbound HTTP requests from a function. To specify egress settings, you must connect the function to a VPC network by using a Serverless VPC Access connector. Egress settings control when traffic is routed through the connector in your VPC network.

Limitations

• Serverless VPC Access only supports routing IPv4 traffic. IPv6 traffic is not supported, even if you have IPv6 routes in your VPC network.

• For added security, Google Cloud blocks egress packets to external IP addresses on TCP destination port 25.

• User functions or services that invoke functions or services protected by a VPC network must route those invocations through a VPC connector.

Configure egress settings

For egress settings, you can specify the following:

• Route only requests to private IPs through the VPC connector: Default. Traffic is routed through the VPC network only if the packets carrying the traffic have destinations that match the following:

  • RFC 1918
  • RFC 6598
  • 199.36.153.4/30 and 199.36.153.8/30

  Packets to any other destination are routed from Cloud Run functions to the internet and not through any VPC network.

• Route all traffic through the VPC connector: Traffic is always routed through the VPC network associated with the connector, for all packet destinations. You must use this option in the following circumstances:

  • If you need to send traffic to VPC subnet ranges with privately used external IP address ranges. For more information about VPC subnet ranges, see Valid IPv4 ranges in the Subnets overview.
  • If you need to send traffic to a Private Service Connect endpoint for Google APIs whose address is a privately used external IP address. For more information about Private Service Connect endpoints for Google APIs, see Access Google APIs through endpoints.
  • If you need to send traffic to any other privately used external IP address destination that's routable within the connector's VPC network. Examples of other destinations covering privately used external IP addresses might include peering subnet ranges, peering subnet ranges created from Allocated IP address ranges for services, and those destinations that are accessible using custom routes in the VPC network.

  If your VPC network includes a default route, packets can still be routed to the internet after being processed by the connector if you configure a Cloud NAT gateway to provide NAT services to the subnet used by the connector. These packets are subject to the routes in your VPC network and the firewall rules that apply to your VPC network. You can use route and firewall configuration to control internet egress for all outbound requests sent by your function through a Serverless VPC Access connector.

You can specify egress settings when you deploy or update your function by using the Google Cloud console or the Google Cloud CLI.

  gcloud functions deploy FUNCTION_NAME 

  --vpc-connector CONNECTOR_NAME 

  --egress-settings EGRESS_SETTINGS 

  FLAGS...
  

Example use cases

The following examples demonstrate how to configure network access in several common scenarios.

Creating a function that cannot be called by external clients

You can secure your HTTP functions by allowing them to be called only by resources in the same Google Cloud project or VPC Service Controls service perimeter.

1. Deploy your function and allow internal traffic only. Use the Google Cloud console or the Google Cloud CLI:

   Console

   1. Open the Functions Overview page in the Google Cloud console:

      Go to the Cloud Run functions Overview page

   2. Click Create function. Alternatively, click an existing function to go to its details page, and click Edit.

   3. Expand the advanced settings by clicking Runtime, build ....

   4. In the Connections section, under Ingress settings, select Allow internal traffic only.

   gcloud

   Use the gcloud functions deploy command:

   gcloud functions deploy FUNCTION_NAME \
   --ingress-settings internal-only \
   FLAGS...
   

After you deploy your function, requests originating from outside of your Google Cloud project are blocked from reaching the function. If you use VPC Service Controls, requests from outside of the service perimeter are blocked. VM instances inside your project or service perimeter can still reach your function by making requests to its HTTPS endpoint.

If you want to call this restricted function from another function, the calling function must route its egress through your VPC network.

Using egress and ingress settings to restrict access

You can incorporate both ingress and egress to your services to add an additional layer of restriction.

1. Clone the cloud-run-sample repository and change to the vpc-sample directory:

   git clone https://github.com/GoogleCloudPlatform/cloud-run-samples
   cd vpc-sample

2. Install Python dependencies:

   pip3 install -r requirements.txt

3. You can open the main.py file in the vpc-sample directory to see the function you are deploying:

   def hello_world(request):
       return "Hello World!"

4. Deploy the function:

   gcloud functions deploy restricted-function 
   
     --runtime=python38 
   
     --trigger-http 
   
     --no-allow-unauthenticated 
   
     --ingress-settings=internal-only 
   
     --entry-point=hello_world

5. Set up a Serverless VPC Access connector:

   gcloud compute networks vpc-access connectors create serverless-connector 
   
     --region=SERVICE_REGION 
   
     --range=10.8.0.0/28

   where SERVICE_REGION is a region for your connector; this must match the region of your serverless service. If your service is in the region us-central or europe-west, use us-central1 or europe-west1.

6. Build your container image:

   gcloud builds submit --tag=gcr.io/PROJECT_ID/restricted-function-caller .

   where PROJECT_ID is the project ID.

   This builds a container image that invokes get_hello_world when deployed from the main.py file:

   import os
   import urllib
   
   import google.auth.transport.requests
   import google.oauth2.id_token
   
   
   def get_hello_world(request):
       try:
           url = os.environ.get("URL")
           req = urllib.request.Request(url)
   
           auth_req = google.auth.transport.requests.Request()
           id_token = google.oauth2.id_token.fetch_id_token(auth_req, url)
           req.add_header("Authorization", f"Bearer {id_token}")
   
           response = urllib.request.urlopen(req)
           return response.read()
   
       except Exception as e:
           print(e)
           return str(e)

7. Use the gcloud run deploy run-function command to deploy the Cloud Run container:

     gcloud run deploy run-function 
   
       --image gcr.io/PROJECT_ID/restricted-function-caller 
   
       --no-allow-unauthenticated 
   
       --update-env-vars=URL=https://SERVICE_REGION-PROJECT_ID.cloudfunctions.net/restricted-function-caller 
   
       --vpc-egress=all 
   
       --vpc-connector=serverless-connector 
   
       --region=SERVICE_REGION

   where:

   • PROJECT_ID is the project ID.
   • SERVICE_REGION is a region for your connector; this must match the region of your serverless service. If your service is in the region us-central or europe-west, use us-central1 or europe-west1.

   The Cloud Run run-function service is now set to send a GET request from the VPC connector to the network-restricted function.

Routing function egress through your VPC network

VPC networks in Google Cloud support a rich set of configurations and networking features. By routing egress traffic from your function into your VPC network, you can ensure that Cloud Run functions egress traffic follows your VPC network's firewall, DNS, routing, and other rules, and you can use products such as Cloud NAT.

1. Set up a VPC network. Configure an existing VPC network or create a new one by following the guide at Using VPC networks.

2. Set up a Serverless VPC Access connector. Cloud Run functions need a Serverless VPC Access connector to route traffic into your VPC network. Create a connector and set up the appropriate permissions by following the instructions at Connecting to a VPC network.

3. Deploy a function that uses the connector and route all egress through the connector. Use the Google Cloud console or the gcloud command-line tool:

   Console

   1. Open the Functions Overview page in the Google Cloud console:

      Go to the Cloud Run functions Overview page

   2. Click Create function. Alternatively, click an existing function to go to its details page, and click Edit.

   3. Expand the advanced settings by clicking Runtime, build ....

   4. In the Connections section, under Egress settings, select your Serverless VPC Access connector and select Route all traffic through the VPC connector.

   gcloud

   Use the gcloud functions deploy command:

   gcloud functions deploy FUNCTION_NAME \
   --vpc-connector CONNECTOR_NAME \
   --egress-settings all \
   FLAGS...
   

After you deploy your function, all traffic originating from your function is routed through your VPC network and adheres to the rules set on your VPC network. Note that your function is unable to access the public internet unless you configure Cloud NAT. Further note that you need your Cloud NAT to map all primary and secondary IP ranges for all subnets to the NAT gateway, in order to include the connector's subnet in the mapping.

Associating function egress with a static IP address

In some cases, you might want traffic originating from your function to be associated with a static IP address. For example, this is useful if you are calling an external service that only allows requests from explicitly specified IP addresses.

1. Route your function's egress through your VPC network. See the previous section, Routing function egress through your VPC network.

2. Set up Cloud NAT and specify a static IP address. Follow the guides at Specify subnet ranges for NAT and Specify IP addresses for NAT to set up Cloud NAT for the subnet associated with your function's Serverless VPC Access connector. Your Cloud NAT must map all primary and secondary IP ranges for all subnets to the NAT gateway to include the connector's subnet in the mapping.

Multi-region load balancing

You can deploy a function to different regions, and allow the request to be be sent to the closest healthy region. To achieve this, you need to set up a serverless network endpoint group (NEG) for the function and connect it to a load balancer, as described in Setting up an HTTP(S) load balancer with serverless NEGs.