Cloud Functions, meet VPC functionality

You probably don’t think of advanced VPC networking features and developer-friendly serverless platforms as things that typically play well together, but increasing numbers of organizations want to use serverless platforms in more traditional IT environments. Here at Google Cloud, we want you to have your serverless cake and eat it too, so are announcing support for new networking controls for Google Cloud Functions, including ingress settings and VPC service controls. 

Serverless VPC Access has been generally available since December, 2019, allowing Cloud Functions to reach into the private IP space of VPC networks. This allows you to route all or internal-only egress traffic to the connected VPC. Today we are extending that with the support of ingress settings, which allows you to control what traffic reaches your Cloud Functions, allowing you to run "private" Cloud Functions. We also support integrating Cloud Functions with VPC Service Controls and organization policies to control the movement of your company's data.

Ingress settings and VPC Service Controls

With the release of Serverless VPC Access, we provided an egress path from functions to services running in a VPC (e.g.,  stateful services running on VMs without public IP addresses or services such as Memorystore). Now with support for ingress settings, you have more control over which network requests can reach your functions.

By default, ingress settings allow traffic to a function from any VPC in your project, or from any internet source. Per function, you can now set ingress to `internal-only`, which excludes any network requests not originating from internal sources inside the same project.

If you want to be more prescriptive about what traffic can reach your functions, you can set up a more explicit perimeter using VPC Service Controls. You can then use ingress and egress settings and the new Organization Policy service to prevent data exfiltration.

You can then combine these network settings in various ways to address a variety of use cases:

• Create a function that can only be called within your VPC network - One of the key uses for network settings is to create a function that can be invoked only by clients within your given project or VPC network, for instance invoking your function from a Compute Engine VM within your VPC network. Here’s an example of how to create such a function.

• Configure a function to connect to private services on a VPC network - Some services are not built to be hardened to the public internet, and rely on network security to control access. You may want your function to be able to reach a service running in your VPC on your own VM or cluster, or a managed service such as Cloud Memorystore. See this example of connecting functions to Redis for rate-limiting.

• Manage function egress with VPC firewalls and NAT - You can use network egress settings to enforce the same security policies and firewall rules applied to the compute instances in the VPC — simply route all traffic through the VPC. If you want all traffic from functions to appear to come from a specific stable IP address, this traffic routing directive can be combined with Cloud NAT.

• Create a security perimeter to protect from Data Exfiltration - Prevent functions from accidentally sending any data to unwanted destinations.

Organization policies

The above use cases show there are many ways to use specific combinations of ingress and egress settings. But for some use cases, such as to protect from data exfiltration, it is important to reduce or remove human error that comes from repeatedly and manually applying resource configurations—especially when your organization already has a defined standard. To address this, Cloud Functions now supports organization policies, which can be applied to Cloud Functions network settings. This lets organizations set strict security policies with proper separation of concerns, while allowing developers to use serverless infrastructure and the flexibility and rapid development it provides.

VPC Connector and Service Controls in action

Multinational insurance provider AXA is an early user of Cloud Functions’ new VPC Connector and VPC Service Controls capabilities, which have emerged as a very useful enabler for creating secure serverless services. Working with Google Cloud Premier Partner Wabion, AXA is using these capabilities for  two very important requirements:

1. VPC-SC for Cloud Functions protects data streams used in GCP against data exfiltration by restricting access to perimeter-secured services only. “Using this functionality, we can ensure that sensitive data cannot be moved to unauthorized services, platforms or GCP projects,” says Felix Jost, GCP Engineering Lead, AXA. “With appropriate organizational policies configured, the policies can be managed on the whole AXA GCP organization to ensure security.”

2. VPC Connector for Cloud Functions enables internal connection to on-premises services. “This allows building hybrid scenarios on serveless services to ensure maximum flexibility and scalability and seamless integration with other automated flows,” Jost says.

We continue to see customers adopt serverless compute platforms like Cloud Functions, and we’re committed to ensuring the serverless workloads you write are first-class citizens of your production Google Cloud environment. To get started with VPC service controls on Cloud Functions please checkout the getting started guide.