Deploy a secured serverless architecture using Cloud Functions

Last reviewed 2023-08-06 UTC

Serverless architectures let you develop software and services without provisioning or maintaining servers. You can use serverless architectures to build applications for a wide range of services.

This document provides opinionated guidance for DevOps engineers, security architects, and application developers on how to help protect serverless applications that use Cloud Functions (2nd gen). The document is part of a security blueprint that consists of the following:

  • A GitHub repository that contains a set of Terraform configurations and scripts.
  • A guide to the architecture, design, and security controls that you implement with the blueprint (this document).

Though you can deploy this blueprint without deploying the Google Cloud enterprise foundations blueprint first, this document assumes that you've already configured a foundational set of security controls as described in the Google Cloud enterprise foundations blueprint. The architecture that's described in this document helps you to layer additional controls onto your foundation to help protect your serverless applications.

To help define key security controls that are related to serverless applications, the Cloud Security Alliance (CSA) published Top 12 Critical Risks for Serverless Applications. The security controls used in this blueprint are designed to address the risks that are relevant to the various use cases described in this document.

Serverless use cases

The blueprint supports the following use cases:

Differences between Cloud Functions and Cloud Run include the following:

  • Cloud Functions is triggered by events, such as changes to data in a database or the receipt of a message from a messaging system such as Pub/Sub. Cloud Run is triggered by requests, such as HTTP requests.
  • Cloud Functions is limited to a set of supported runtimes. You can use Cloud Run with any programming language.
  • Cloud Functions manages containers and the infrastructure that controls the web server or language runtime so that you can focus on your code. Cloud Run provides the flexibility for you to run these services yourself, so that you have control of the container configuration.

For more information about differences between Cloud Run and Cloud Functions, see Choosing a Google Cloud compute option.

Architecture

This blueprint uses a Shared VPC architecture, in which Cloud Functions is deployed in a service project and can access resources that are located in other VPC networks.

The following diagram shows a high-level architecture, which is further described in the example architectures that follow it.

The architecture for the serverless blueprint using Cloud Functions.

The architecture that's shown in the preceding diagram uses a combination of the following Google Cloud services and features:

  • Cloud Functions lets you run functions as a service and manages the infrastructure on your behalf. By default, this architecture deploys Cloud Functions with an internal IP address only and without access to the public internet.
  • The triggering event is the event that triggers Cloud Functions. As further described in the example architectures, this can be a Cloud Storage event, a scheduled interval, or a change in BigQuery.
  • Artifact Registry stores the source containers for your Cloud Functions application.
  • Shared VPC lets you connect a Serverless VPC Access connector in your service project to the host project. You deploy a separate Shared VPC network for each environment (production, non-production, and development). This networking design provides network isolation between the different environments. A Shared VPC network lets you centrally manage network resources in a common network while delegating administrative responsibilities for the service project.
  • The Serverless VPC Access connector connects your serverless application to your VPC network using Serverless VPC Access. Serverless VPC Access helps to ensure that requests from your serverless application to the VPC network aren't exposed to the internet. Serverless VPC Access lets Cloud Functions communicate with other services, storage systems, and resources that support VPC Service Controls.

    You can configure Serverless VPC Access in the Shared VPC host project or a service project. By default, this blueprint deploys Serverless VPC access in the Shared VPC host project to align with the Shared VPC model of centralizing network configuration resources. For more information, see Comparison of configuration methods.

  • VPC Service Controls creates a security perimeter that isolates your Cloud Functions services and resources by setting up authorization, access controls, and secure data exchange. This perimeter is designed to isolate your application and managed services by setting up additional access controls and monitoring, and to separate your governance of Google Cloud from the application. Your governance includes key management and logging.

  • The consumer service is the application that is acted on by Cloud Functions. The consumer service can be an internal server or another Google Cloud service such as Cloud SQL. Depending on your use case, this service might be behind Cloud Next Generation Firewall, in another subnet, in the same service project as Cloud Functions, or in another service project.

  • Secure Web Proxy is designed to secure the egress web traffic, if required. It enables flexible and granular policies based on cloud identities and web applications. This blueprint uses Secure Web Proxy for granular access policies to egress web traffic during the build phase of Cloud Functions. The blueprint adds an allowed list of URLs to the Gateway Security Policy Rule.

  • Cloud NAT provides outbound connection to the internet, if required. Cloud NAT supports source network address translation (SNAT) for compute resources without public IP addresses. Inbound response packets use destination network address translation (DNAT). You can disable Cloud NAT if Cloud Functions doesn't require access to the internet. Cloud NAT implements the egress network policy that is attached to Secure Web Proxy.

  • Cloud Key Management Service (Cloud KMS) stores the customer-managed encryption keys (CMEKs) that are used by the services in this blueprint, including your serverless application, Artifact Registry, and Cloud Functions.

  • Secret Manager stores the Cloud Functions secrets. The blueprint mounts secrets as a volume to provide a higher level of security than passing secrets as environment variables.

  • Identity and Access Management (IAM) and Resource Manager help to restrict access and isolate resources. The access controls and resource hierarchy follow the principle of least privilege.

  • Cloud Logging collects all the logs from Google Cloud services for storage and retrieval by your analysis and investigation tools.

  • Cloud Monitoring collects and stores performance information and metrics about Google Cloud services.

Example architecture with a serverless application using Cloud Storage

The following diagram shows how you can run a serverless application that accesses an internal server when a particular event occurs in Cloud Storage.

Example serverless architecture with Cloud Storage.

In addition to the services described in Architecture, this example architecture uses a combination of the following Google Cloud services and features:

  • Cloud Storage emits an event when any cloud resource, application, or user creates a web object on a bucket.
  • Eventarc routes events from different resources. Eventarc encrypts events in transit and at rest.
  • Pub/Sub queues events that are used as the input and a trigger for Cloud Functions.
  • Virtual Private Cloud (VPC) firewall rules control the flow of data into the subnet that hosts your resources, such as an internal server.
  • The internal server runs on Compute Engine or Google Kubernetes Engine and hosts your internal application. If you deploy the Secure Cloud Functions with Internal Server Example, you deploy an Apache server with a Hello World HTML page. This example simulates access to an internal application that runs VMs or containers.

Example architecture with Cloud SQL

The following diagram shows how you can run a serverless application that accesses a Cloud SQL hosted service at a regular interval that is defined in Cloud Scheduler. You can use this architecture when you must gather logs, aggregate data, and so on.

Example serverless architecture with Cloud SQL.

In addition to the services described in Architecture, this example architecture uses a combination of the following Google Cloud services and features:

Example architecture with BigQuery data warehouse

The following diagram shows how you can run a serverless application that is triggered when an event occurs in BigQuery (for example, data is added or a table is created).

Example serverless architecture with BigQuery.

In addition to the services described in Architecture, this example architecture uses a combination of the following Google Cloud services and features:

Organization structure

Resource Manager lets you logically group resources by project, folder, and organization.

The following diagram shows a resource hierarchy with folders that represent different environments such as bootstrap, common, production, non-production (or testing), and development. This resource hierarchy is based on the hierarchy that's described in the enterprise foundations blueprint. You deploy the projects that the blueprint specifies into the following folders: Common, Production, Non-production, and Dev.

The organization structure for the serverless blueprint.

The following sections describe this diagram in more detail.

Folders

You use folders to isolate your production environment and governance services from your non-production and testing environments. The following table describes the folders from the enterprise foundations blueprint that are used by this blueprint.

Folder Description
Bootstrap Contains resources required to deploy the enterprise foundations blueprint.
Common Contains centralized services for the organization, such as the security project.
Production Contains projects that have cloud resources that have been tested and are ready to be used by customers. In this blueprint, the Production folder contains the service project and host project.
Non-production Contains projects that have cloud resources that are currently being tested and staged for release. In this blueprint, the Non-production folder contains the service project and host project.
Development Contains projects that have cloud resources that are currently being developed. In this blueprint, the Development folder contains the service project and host project.

You can change the names of these folders to align with your organization's folder structure, but we recommend that you maintain a similar structure. For more information, see Organization structure. For other folder structures, see Decide a resource hierarchy for your Google Cloud landing zone.

Projects

You isolate resources in your environment using projects. The following table describes the projects that are needed within the organization. You can change the names of these projects, but we recommend that you maintain a similar project structure.

Project Description
Shared VPC host project

This project includes the firewall ingress rules and any resources that have internal IP addresses (as described in Connect to a VPC network). When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it.

When you apply the Terraform code, you specify the name of this project, and the blueprint deploys Serverless VPC Access connector, Cloud NAT, and Cloud Secure Web Proxy.

Shared VPC service project

This project includes your serverless application, Cloud Functions, and the Serverless VPC Access connector. You attach the service project to the host project so that the service project can participate in the Shared VPC network.

When you apply the Terraform code, you specify the name of this project. The blueprint deploys Cloud Functions and services needed for your use case, such as Cloud SQL, Cloud Scheduler, Cloud Storage, or BigQuery.

When you apply the Terraform code, you specify the name of this project, and the blueprint deploys Cloud KMS. If you use the Secure Serverless Harness module in the serverless blueprint for Cloud Functions, Artifact Registry is also deployed.

Security project

This project includes your security-specific services, such as Cloud KMS and Secret Manager.

The default name of the security project is prj-bu1-p-sec. If you deploy this blueprint after you deploy the security foundations blueprint, the security project project is created in addition to the enterprise foundation blueprint's secrets project (prj-bu1-p-env-secrets). For more information about the enterprise foundations blueprint projects, see Projects.

If you deploy multiple instances of this blueprint without the enterprise foundations blueprint, each instance has its own security project.

Mapping roles and groups to projects

You must give different user groups in your organization access to the projects that make up the serverless architecture. The following table describes the blueprint recommendations for user groups and role assignments in the projects that you create. You can customize the groups to match your organization's existing structure, but we recommend that you maintain a similar segregation of duties and role assignment.

Group Project Roles
Serverless administrator
grp-gcp-serverless-admin@example.com
Service project
Serverless security administrator
grp-gcp-serverless-security-admin@example.com
Security project
Cloud Functions developer
grp-gcp-secure-cloud-run-developer@example.com
Security project
Cloud Functions user
grp-gcp-secure-cloud-run-user@example.com
Shared VPC service project

Security controls

This section discusses the security controls in Google Cloud that you use to help secure your serverless architecture. The key security principles to consider are as follows:

  • Secure access according to the principle of least privilege, giving principals only the privileges required to perform tasks.
  • Secure network connections through trust boundary design, which includes network segmentation, organization policies, and firewall policies.
  • Secure configuration for each of the services.
  • Identify any compliance or regulatory requirements for the infrastructure that hosts serverless workloads and assign a risk level.
  • Configure sufficient monitoring and logging to support audit trails for security operations and incident management.

Build system controls

When you deploy your serverless application, you use Artifact Registry to store the container images and binaries. Artifact Registry supports CMEK so that you can encrypt the repository using your own encryption keys.

Network and firewall rules

Virtual Private Cloud (VPC) firewall rules control the flow of data into the perimeters. You create firewall rules that deny all egress, except for specific TCP port 443 connections from restricted.googleapis.com special domain names. Using the restricted.googleapis.com domain has the following benefits:

  • It helps to reduce your network attack surface by using Private Google Access when workloads communicate with Google APIs and services.
  • It ensures that you use only services that support VPC Service Controls.

In addition, you create a DNS record to resolve *.googleapis.com to restricted.googleapis.com.

For more information, see Configuring Private Google Access.

Perimeter controls

As shown in the Architecture section, you place the resources for the serverless application in a separate VPC Service Controls security perimeter. This perimeter helps reduce the broad impact from a compromise of systems or services. However, this security perimeter doesn't apply to the Cloud Functions build process when Cloud Build automatically builds your code into a container image and pus