Configure VPC Service Controls

Note: This content applies only to Cloud Run functions—formerly Cloud Functions (2nd gen).

For the 1st gen version of this document, see Configure VPC Service Controls (1st gen).

VPC Service Controls is a Google Cloud feature that lets you set up a secure perimeter to guard against data exfiltration. This guide shows how to use VPC Service Controls with Cloud Run functions to add additional security to your functions.

For limitations with this integration, see the VPC Service Controls documentation.

Organization-level setup

To use VPC Service Controls with Cloud Run functions, you can configure a service perimeter at the organization level. By configuring appropriate organization policies, you can ensure that VPC Service Controls checks are enforced when using Cloud Run functions and that developers can only deploy services compliant with VPC Service Controls. Learn more about inheritance and violations when setting an organization policy.

Set up a VPC Service Controls perimeter

To set up a service perimeter, you need the Organization Viewer (roles/resourcemanager.organizationViewer) and Access Context Manager Editor (roles/accesscontextmanager.policyEditor) roles.

Follow the VPC Service Controls Quickstart to:

1. Create a service perimeter.

   Note: Cloud Run functions uses Cloud Build, Artifact Registry, Container Registry (Deprecated), and Cloud Storage to build and manage your source code in a runnable container. If these services are restricted by the service perimeter, VPC Service Controls blocks the Cloud Run functions build, even if Cloud Run functions is not added as a restricted service to the perimeter. To use Cloud Run functions inside a service perimeter, configure an ingress rule for the Cloud Build service account in your service perimeter. Cloud Build also uses Cloud Logging, which can fail to log properly if a VPC-SC perimeter restricts it. This won't cause builds to fail, but we recommend granting Cloud Build access to the service perimeter with an ingress rule to ensure proper logging.

2. Add one or more projects to the perimeter.

   Note: If you are using Shared VPC, make sure to add the host project and service projects to the same perimeter.

3. Restrict the Cloud Functions API and the Cloud Run Admin API.

After setting up your service perimeter, all calls to the restricted API are checked to ensure that the calls originate from within the same perimeter.

Optional: Enable perimeter access for development machines

Because VPC Service Controls checks are enforced for the Cloud Functions API, calls to the Cloud Functions API fail unless they originate from within the service perimeter. Thus, to manage functions with the Cloud Functions API, the Cloud Run functions UI in the Google Cloud console, or the Google Cloud CLI, choose one of the following options:

• Use a machine inside the VPC Service Controls perimeter. For example, you can use a Compute Engine VM or an on-premises machine connected to your VPC network using a VPN.

• Grant function developers access to the perimeter. For example, you can create access levels that enable perimeter access based on IP address or user identity. See Allowing access to protected resources from outside a perimeter for more information.

Set up organization policies

To manage organization policies, you need the Organization Policy Administrator (roles/orgpolicy.policyAdmin) role.

To comply with VPC Service Controls and protect against data exfiltration, set up the following organization policies that control the allowable network settings for Cloud Run functions in the service perimeter.

Note: The organization policies go into effect for new function deployments. Existing functions continue to work and might pose an exfiltration risk until they are redeployed with the allowed settings. See Audit existing functions to ensure VPC Service Controls compliance.

Restrict allowed ingress settings

The run.allowedIngress organization policy controls the ingress settings that developers are allowed to use for Cloud Run functions. Set this organization policy to mandate that developers use the internal value:

Console

1. Go to the Allowed ingress settings policy page in the Google Cloud console:

   Go to organization policy

2. Click Manage Policy.

3. On the Edit policy page, select Customize.

4. Under Policy enforcement, select Replace.

5. Under Policy values, select Custom.

6. Under Policy type, select Allow.

7. Under Custom values, enter internal.

8. Click Set Policy.

gcloud

Use the gcloud resource-manager org-policies allow command:

gcloud resource-manager org-policies allow \
  run.allowedIngress internal \
  --organization ORGANIZATION_ID

where ORGANIZATION_ID is your organization ID.

After this organization policy is in place, all functions must use the internal value for their ingress settings. This means that HTTP functions can only accept traffic originating from a VPC network within the service perimeter. Function deployments specifying a different value will fail.

Restrict allowed VPC connector egress settings

The run.allowedVPCEgress organization policy controls the egress settings that developers are allowed to use for Cloud Run functions. Set this organization policy to allow only the all traffic value:

Console

1. Go to the Allowed VPC Connector egress settings policy page in the Google Cloud console:

   Go to organization policy

2. Click Manage policy.

3. On the Edit policy page, select Customize.

4. Under Policy enforcement, select Replace.

5. Under Policy values, select Custom.

6. Under Policy type, select Allow.

7. Under Custom values, enter all-traffic.

8. Click Set Policy.

gcloud

Use the gcloud resource-manager org-policies allow command:

gcloud resource-manager org-policies allow \
  run.allowedVPCEgress all-traffic \
  --organization ORGANIZATION_ID

where ORGANIZATION_ID is your organization ID.

After this organization policy is in place, all functions must use the all-traffic value for their egress settings. This means that functions must route all egress traffic through your VPC network. Function deployments specifying a different value will fail.

Combined with the cloudfunctions.requireVPCConnector organization policy, this forces all egress traffic to traverse the VPC network where it is subject to its configured firewall and routing rules.

Project-level setup

For individual projects within the service perimeter, you must perform additional configuration to use VPC Service Controls.

Configure VPC networks

To access Google APIs and services while mitigating data exfiltration risks, requests should be sent to the restricted virtual IP (VIP) range, 199.36.153.4/30 (restricted.googleapis.com).

For each VPC network in a project, follow these steps to block outbound traffic except for traffic to the restricted VIP range:

1. Configure firewall rules to prevent data from leaving the VPC network:

   Caution: Failure to correctly configure firewall rules could leave your functions vulnerable to data exfiltration.

   • Create a deny egress rule that blocks all outbound traffic.

     Note: Ensure the deny all egress firewall rule has a priority after 1000. Otherwise, traffic from the Serverless VPC Access connector to your function will be blocked.

   • Create an allow egress rule that permits traffic to 199.36.153.4/30 on TCP port 443. Ensure that it has a priority before the deny egress rule you just created—this allows egress only to the restricted VIP range.

2. Configure DNS to resolve *.googleapis.com to restricted.googleapis.com.

3. Configure DNS with an A record mapping *.cloudfunctions.net to the 199.36.153.4/30 IP range. You can do this with Cloud DNS:

   gcloud dns managed-zones create ZONE_NAME \
   --visibility=private \
   --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/VPC_NAME \
   --description=none \
   --dns-name=cloudfunctions.net
   
   gcloud dns record-sets transaction start --zone=ZONE_NAME
   
   gcloud dns record-sets transaction add --name=*.cloudfunctions.net. \
   --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \
   --zone=ZONE_NAME \
   --ttl=300
   
   gcloud dns record-sets transaction execute --zone=ZONE_NAME
   

   Note: ZONE_NAME must be different than the name used to set up the *.googleapis.com rules in step 2.
   Note: In some terminals, you may need to add double quotes around the value for the --name flag (for example, --name="\*.cloudfunctions.net.") that is passed to the gcloud record-sets transaction add command.

4. Enable Private Google Access for your VPC Connector's Subnet.

   Note: This is only necessary if you specified your own subnet when creating the VPC Connector. If you instead created the connector using a Custom IP Range, a Google managed subnet was created for you with Private Google Access enabled.

At this point, requests originating from within the VPC network:

• are not able to leave the VPC network, preventing egress outside the service perimeter.
• can only reach Google APIs and services that check VPC Service Controls, preventing exfiltration through Google APIs.

Grant the Cloud Build service account access to the VPC Service Controls perimeter

Cloud Run functions uses Cloud Build to build your source code into a runnable container. To use Cloud Run functions with VPC Service Controls, you must configure your Cloud Build service account (whether default or custom) to have access to your service perimeter.

Note: The default Cloud Build service account may have changed starting in May 2024. Review Cloud Build service account change to confirm the default service account for your project before proceeding.

Find the service account name

If you are using the default Cloud Build service account, you can find its name as follows:

1. Use the IAM page in the Google Cloud console to find the Cloud Build service account.

   Open IAM

2. Make sure the correct project is displayed in the project drop down.

3. Search for cloudbuild.gserviceaccount.com. The email address in the form [e-mail] is the service account name.

If you have a custom Cloud Build service account, use that name instead.

Grant the service account access to the service perimeter

Once you have the service account name, follow the guide at Limit access by user or service account to create an access level for the service account. Then, follow Adding an access level to an existing perimeter to add the access level to your service perimeter.

Deploy functions compliant with VPC Service Controls

After VPC Service Controls is configured for Cloud Run functions, you must ensure that all functions deployed within the service perimeter comply with the specified organization policies. This means that:

• All functions must use a Serverless VPC Access connector. See Connecting to a VPC network for more information.
• All functions must allow only traffic from internal sources. See Ingress settings for more information.
• All functions must route all outgoing traffic through the VPC network. See Egress settings for more information.

Function deployments that don't meet these criteria will fail.

Audit existing functions to ensure VPC Service Controls compliance

After setting up VPC Service Controls, new functions created in projects within the service perimeter are automatically checked for compliance. However, to avoid disruption of existing workloads, existing functions continue to work and might not comply with organization policies.

We recommend that you audit existing functions and update or redeploy functions as necessary. To facilitate this process, you might create a script that uses the Cloud Functions API to list your functions and highlight those that don't specify the proper network settings.

Using VPC Service Controls with functions outside a perimeter

The preceding sections apply to the scenario where you deploy Cloud Run functions within a VPC Service Controls service perimeter.

If you need to deploy a function outside of a service perimeter but the function requires access to resources inside a perimeter, use the following configuration:

1. Grant the Cloud Build service account access to the VPC Service Controls perimeter.
2. Grant the function's runtime service account access to the perimeter. You can do this either by creating an access level and adding the access level to the service perimeter, or by creating an ingress policy on the perimeter.
3. Connect the function to a VPC network.
4. Route all outgoing traffic from the function through the VPC network. See Egress settings for more information.

After you complete this configuration, the function will be able to reach resources protected by the perimeter.