Please refer to Secure Serverless Blueprint Guide and accompanying Terraform repo update for more detail.

Serverless architectures enable customers to avoid the time-consuming process of applying security patches, controls  and agents to the underlying operating system and application servers.  The responsibility for safeguarding the data center, network, servers, operating systems, and their configurations is shifted to the serverless provider (Google Cloud).  Application logic, code, data, and application-layer configurations, on the other hand, must all be secured and made resistant to attacks by the application owner.  This blueprint deploys Cloud Run services and, more importantly, the ancillary services supporting the serverless application.  All services and their respective configurations have used best practices which were informed by The 12 Most Critical Risks for Serverless Applications, a CSA research publication.  The guide and blueprint are designed around five Cloud Foundation Toolkit Cloud Run submodules: secure-cloud-run, secure-cloud-run-core, secure-cloud-run-harness, secure-cloud-run-net and secure-cloud-run-security.

• This will accelerate consumption or security and serverless services, especially for highly regulated customers
• We will maintain and support this blueprint in perpetuity through our Blueprints Center of Excellence; including updates with new controls as they become generally available.
• Future iterations will include Cloud Functions 2nd gen (and ancillary services), support for Eventarc, example common queries, sample alerts  and more!

Default enabled security controls and governance include:  

• Secure access to deployed services according to the principle of least privileged access with user group creation and role assignment
• Creation of service accounts and service identities whose roles map directly to their specific purposes
• Prescriptive architecture, design and configurations for segmenting and securing the network with firewall rules and a VPC Service-Controls Perimeter
• Protected serverless service load balancing through a preconfigured Cloud Armor WAF rules
• Build system controls through an encrypted Artifact Registry repository
• Private connectivity to VPC network with Serverless Connector
• Traffic management and control for internal LB only traffic.
• Advanced key management (using CMEK) that can be used to protect your container images and Cloud Run service
• Opinionated support for Secrets using Secret Manager and secrets presented as mounted volumes
• Organization policies that restrict traffic ingressing and egressing the Cloud Run service
• Logging, monitoring, health analytics and threat detection services

Customers have several options to leverage the blueprint guide and Terraform template:

• (Recommended) Users can apply it on-top of the security foundations blueprint in an integrated stack
  • The resources deployed in this blueprint are in the same perimeter used by security foundations blueprint
  • The security foundations blueprint’s secrets project is used to house Artifact Registry, Cloud KMS and Secret Manager
• Users can deploy it directly out-of-the-box with either their existing brownfield estates
• Users can deploy it in standalone mode to experiment or POC  using the provided external harness infrastructure
• Users can customize ancillary modules to enhance the security of their existing deployments

You can learn more about

• Security blueprints at the Cloud Security Best Practices page
• Curated architectures for Secured Landing Zone, Confidential Data Warehouse, Secured Serverless  at the Architecture Center

---

Reference: https://cloud.google.com/architecture/serverless-blueprint

Deploy a secure serverless architecture

Approved by the Google Cybersecurity Action Team.

Preview

This product or feature is covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service. Pre-GA products and features might have limited support, and changes to pre-GA products and features might not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.

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 and application engineers on how to help protect serverless applications that use Cloud Run. 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).

The document assumes that you’ve already configured a foundational set of security controls as described in the Google Cloud security foundations blueprint. The architecture that’s described in this document helps you layer additional controls onto your existing foundation to help protect your serverless applications.

Architecture

This blueprint lets you run serverless applications on Cloud Run with Shared VPC. We recommend that you use Shared VPC because it centralizes network policy and control for all networking resources. In addition, Shared VPC is deployed in the security foundations blueprint.

Recommended architecture: Cloud Run with a Shared VPC network

The following image shows how you can run your serverless applications in a Shared VPC network.

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

• External HTTP(S) Load Balancing receives the data that serverless applications require from the internet and forwards it to Cloud Run. External HTTP(S) Load Balancing is a Layer 7 load balancer.
• Google Cloud Armor acts as the web application firewall to help protect your serverless applications against denial of service (DoS) and web attacks.
• Cloud Run lets you run application code in containers and manages the infrastructure on your behalf. In this blueprint, the Internal and Cloud Load Balancing ingress setting restricts access to Cloud Run so that Cloud Run will accept requests only from the external HTTP(S) load balancer.
• 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 Run communicate with other services, storage systems, and resources that support VPC Service Controls.By default, you create the Serverless VPC Access connector in the service project. You can create the Serverless VPC Access connector in the host project by specifying true for the connector_on_host_project input variable when you run the Secure Cloud Run Network module. For more information, see Comparison of configuration methods.
• Virtual Private Cloud (VPC) firewall rules control the flow of data into the subnet that hosts your resources, such as a company server hosted on Compute Engine, or company data stored in Cloud Storage.
• VPC Service Controls creates a security perimeter that isolates your Cloud Run services and resources by setting up authorization, access controls, and secure data exchange. This perimeter is designed to protect incoming content, to isolate your application 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.
• Shared VPC lets you connect the Serverless VPC Access connector in your service project to the host project.
• 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 Run.
• 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.

Alternative architecture: Cloud Run without a Shared VPC network

If you’re not using a Shared VPC network, you can deploy Cloud Run and your serverless application in a VPC Service Control perimeter without a Shared VPC network. You might implement this alternative architecture if you’re using a hub-and-spoke topology.

The following image shows how you can run your serverless applications without Shared VPC.

The architecture that’s shown in the preceding diagram uses a combination of Google Cloud services and features that’s similar to those that are described in the previous section, Recommended architecture: Cloud Run with a shared VPC.

Organization structure

You group your resources so that you can manage them and separate your development and testing environments from your production environment. 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 security foundations blueprint. You deploy the projects that the blueprint specifies into the following folders: Common, Production, Non-production, and Dev.

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 security foundations blueprint that are used by this blueprint.

Folder	Description
Bootstrap	Contains resources required to deploy the security 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 use 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.
Dev	Contains projects that have cloud resources that are currently being developed. In this blueprint, the Dev 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 The example.com Google Cloud 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
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 the services.
Service project	This project includes your serverless application, Cloud Run, 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 Run, Google Cloud Armor, Serverless VPC Access connector, and the load balancer.
Security project	This project includes your security-specific services, such as Cloud KMS and Secret Manager. When you apply the Terraform code, you specify the name of this project, and the blueprint deploys Cloud KMS. If you use the Secure Cloud Run Harness module, Artifact Registry is also deployed. If you deploy this blueprint after you deploy the security foundations blueprint, this project is the secrets project created by the security foundations blueprint. For more information about the security foundations blueprint projects, see Using the Terraform example. If you deploy multiple instances of this blueprint without the security 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	roles/run.adminroles/compute.networkViewercompute.networkUser
Serverless security administrator grp-gcp-serverless-security-admin@example.com	Security project	roles/run.viewerroles/cloudkms.viewerroles/artifactregistry.reader
Cloud Run developer grp-gcp-secure-cloud-run-developer@example.com	Security project	roles/run.developerroles/artifactregistry.writerroles/cloudkms.cryptoKeyEncrypter
Cloud Run user grp-gcp-secure-cloud-run-user@example.com	Service project	roles/run.invoker

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 entities only the privileges required to perform their tasks.
• Secure network connections through segmentation design, organization policies, and firewall policies.
• Secure configuration for each of the services.
• Understand the risk levels and security requirements for the environment that hosts your serverless workloads.
• Configure sufficient monitoring and logging to allow detection, investigation, and response.

Security controls for serverless applications

You can help to protect your serverless applications using controls that protect traffic on the network, control access, and encrypt data.

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.

SSL traffic

To support HTTPS traffic to your serverless application, you configure an SSL certificate for external HTTP(S) Load Balancing. By default, you use a self-signed certificate that you can change to a managed certificate after you apply the Terraform code. For more information about installing and using managed certificates, see Using Google-managed SSL certificates.

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 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.

For more information, see Configuring Private Google Access.

Perimeter controls

As shown in the recommended-architecture diagram, you place the resources for the serverless application in a separate perimeter. This perimeter helps protect the serverless application from unintended access and data exfiltration.

Access policy

To help ensure that only specific identities (users or services) can access resources and data, you enable IAM groups and roles.

To help ensure that only specific resources can access your projects, you enable an access policy for your Google organization. For more information, see Access level attributes.

Identity and Access Proxy

If your environment already includes Identity and Access Proxy (IAP), you can configure external HTTP(S) Load Balancing to use IAP to authorize traffic for your serverless application. IAP lets you establish a central authorization layer for your serverless application so that you can use application-level access controls instead of relying on network-level firewalls.

To enable IAP for your application, in the loadbalancer.tf file, set iap_config.enable to true.

For more information about IAP, see Identity-Aware Proxy overview.

Service accounts and access controls

Service accounts are identities that Google Cloud can use to run API requests on your behalf. To implement separation of duties, you create service accounts that have different roles for specific purposes. The service accounts are as follows:

• A Cloud Run service account (cloud_run_sa) that has the following roles:
  • roles/run.invoker
  • roles/secretmanager.secretAccessor
  For more information, see Allow Cloud Run to access a secret.
• A Serverless VPC Access connector account (gcp_sa_vpcaccess) that has the roles/compute.networkUser role.
• A second Serverless VPC Access connector account (cloud_services) that has the roles/compute.networkUser role.These service accounts for the Serverless VPC Access connector are required so that the connector can create the firewall ingress and egress rules in the host project. For more information, see Grant permissions to service accounts in your service projects.
• A service identity to run Cloud Run (run_identity_services) that has the roles/vpcaccess.user role.
• A service agent for the Google APIs (cloud_services_sa) that has the roles/editor role. This service account lets Cloud Run communicate with the Serverless VPC Access connector.
• A service identity for Cloud Run (serverless_sa) that has the roles/artifactregistry.reader role. This service account provides access to Artifact Registry and CMEK encryption and decryption keys.

Key management

You use the CMEK keys to help protect your data in Artifact Registry and in Cloud Run. You use the following encryption keys:

• A software key for Artifact Registry that attests the code for your serverless application.
• An encryption key to encrypt the container images that Cloud Run deploys.

When you apply the Terraform configuration, you specify the CMEK location, which determines the geographical location where the keys are stored. You must ensure that your CMEK keys are in the same region as your resources. By default, CMEK keys are rotated every 90 days.

Secret management

Cloud Run supports Secret Manager to store the secrets that your serverless application might require. These secrets can include API keys and database usernames and passwords. To expose the secret as a mounted volume, use the volume_mounts and volumes variables in the main module.

When you deploy this blueprint with the security foundations blueprint, you must add your secrets to the secrets project before you apply the Terraform code. The blueprint will grant the Secret Manager Secret Accessor role to the Cloud Run service account. For more information, see Use secrets.

Organization policies

This blueprint adds constraints to the organization policy constraints that the security foundations blueprint uses. For more information about the constraints that the security foundations blueprint uses, see Organization policy setup.

The following table describes the additional organization policy constraints that are defined in the Secure Cloud Run Security module of this blueprint.

Policy constraint	Description	Recommended value
constraints/run.allowedIngress	Allow ingress traffic only from internal services or the external HTTP(S) load balancer.	internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress	Require a Cloud Run service’s revisions to use a Serverless VPC Access connector, and ensure that the revisions’ VPC egress settings are set to allow private ranges only.	private-ranges-only

Operational controls

You can enable logging and Security Command Center Premium tier features such as security health analytics and threat detection. These controls help you to do the following:

• Monitor who is accessing your data.
• Ensure that proper auditing is in place.
• Support the ability of your incident management and operations teams to respond to issues that might occur.

Logging

To help you meet auditing requirements and get insight into your projects, you configure the Google Cloud operations suite with data logs for the services that you want to track. Deploy Cloud Logging in the projects before you apply the Terraform code to ensure that the blueprint can configure logging for the firewall, load balancer, and VPC network.

After you deploy the blueprint, we recommend that you configure the following:

• Create an aggregated log sink across all projects.
• Select the appropriate region to store your logs.
• Add CMEK keys to your logging sink.

For all services within the projects, ensure that your logs include information about data reads and writes, and ensure that they include information about what administrators access. For more information about logging best practices, see Logging and monitoring.

Monitoring and alerts

After you deploy the blueprint, you can set up alerts to notify your security operations center (SOC) that a security incident might be occurring. For example, you can use alerts to let your security analysts know when a permission has changed in an IAM role. For more information about configuring Security Command Center alerts, see Setting up finding notifications.

The Cloud Run Monitoring dashboard, which is part of the sample dashboard library, provides you with the following information:

• Request count
• Request latency
• Billable instance time
• Container CPU allocation
• Container memory allocation
• Container CPU utilization
• Container memory utilization

For instructions on importing the dashboard, see Install sample dashboards. To export alerts, see the following documents:

• Introduction to alerting
• Cloud Monitoring metric export

Detective controls

This section describes the detective controls that are included in the blueprint.

Google Cloud Armor and WAF

You use HTTP(S) Load Balancing and Google Cloud Armor to provide distributed denial of service (DDoS) protection for your serverless application. Google Cloud Armor is the web application firewall (WAF) included with Google Cloud.

You configure the Google Cloud Armor rules described in the following table to help protect the serverless application. The rules are designed to help mitigate against OWASP Top 10 risks.

Google Cloud Armor rule name	ModSecurity rule name
Remote code execution	rce-v33-stable
Local file include	lfi-v33-stable
Protocol attack	protocolattack-v33-stable
Remote file inclusion	rfi-v33-stable
Scanner detection	scannerdetection-v33-stable
Session fixation attack	sessionfixation-v33-stable
SQL injection	sqli-v33-stable
Cross-site scripting	xss-v33-stable

When these rules are enabled, Google Cloud Armor automatically denies any traffic that matches the rule.

For more information about these rules, see Tune Google Cloud Armor preconfigured WAF rules.

Security issue detection in Cloud Run

You can detect potential security issues in Cloud Run using Recommender. Recommender can detect security issues such as the following:

• API keys or passwords that are stored in environment variables instead of in Secret Manager.
• Containers that include hard-coded credentials instead of using service identities.

About a day after you deploy Cloud Run, Recommender starts providing its findings and recommendations. Recommender displays its findings and recommended corrective actions in the Cloud Run service list or the Recommendation Hub.

Terraform deployment modes

The following table describes the ways that you can deploy this blueprint, and which Terraform modules apply for each deployment mode.

Deployment mode	Terraform modules
Deploy this blueprint after deploying the security foundations blueprint (recommended). This option deploys the resources for this blueprint in the same VPC Service Controls perimeter that is used by the security foundations blueprint. For more information, see How to customize Foundation v2.3.1 for Secure Serverless deployment. This option also uses the secrets project that you created when you deployed the security foundations blueprint.	Use these Terraform modules: secure-cloud-run-coresecure-cloud-run-netsecure-cloud-run-securitysecure-cloud-run
Install this blueprint without installing the security foundations blueprint. This option requires that you create a VPC Service Controls perimeter.	Use these Terraform modules: secure-cloud-run-coresecure-cloud-run-harnesssecure-cloud-run-netsecure-cloud-run-securitysecure-cloud-run

Bringing it all together

To implement the architecture described in this document, do the following:

1. Review the README for the blueprint and ensure that you meet all the prerequisites.
2. Create an SSL certificate for use with the HTTP(S) Load Balancing.
   If you do not complete this step, the blueprint uses a self-signed certificate to deploy the load balancer, and your browser will display warnings about insecure connections when you attempt to access your serverless application.
3. In your testing environment, deploy the Secure Cloud Run Example to see the blueprint in action. As part of your testing process, consider doing the following:
   1. Use Security Command Center to scan the projects against common compliance requirements.
   2. Replace the sample application with a real application and run through a typical deployment scenario.
   3. Work with the application engineering and operations teams in your enterprise to test their access to the projects and to verify whether they can interact with the solution in the way that they would expect.
4. Deploy the blueprint into your environment.

Compliance mappings

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 help you address most of these risks, as described in the following table.

Risk	Blueprint mitigation	Your responsibility
1. Function event-data injection	Google Cloud Armor and external HTTP(S) Load Balancing help protect against OWASP Top 10, as described in OWASP Top 10 2021 mitigation options on Google Cloud	Secure coding practices such as exception handling, as described in the OWASP Secure Coding Practices and Supply chain Levels for Software Artifacts (SLSA)
2. Broken authentication	None	IAP and Identity Platform to authenticate users to the service
3. Insecure serverless deployment configuration	CMEK with Cloud KMS	Management of your own encryption keys
4. Over-privileged function permissions and roles	Custom service account for service authentication (not the default Compute Engine service account)Tightly-scoped IAM roles on the Cloud Run service accountVPC Service Controls to limit scope of Google Cloud API access (as provided using the Google Cloud security foundations)	None
5. Inadequate function monitoring and logging	Cloud Logging	Cloud Monitoring dashboards and alerting structure
6. Insecure third-party dependencies	None	Protect the CI/CD pipeline using code scanning and pre-deployment analysis
7. Insecure application secrets storage	Secret Manager	Secret management in application code
8. Denial of service and financial resource exhaustion	Google Cloud ArmorCloud Run service timeouts (default is 120 seconds)	None
9. Serverless business logic manipulation	VPC Service Controls to limit scope of Google Cloud API access (provided using security foundations blueprint)	None
10. Improper exception handling and verbose error messages	None	Secure programming best practices
11. Obsolete functions, cloud resources, and event triggers	Use revisions to minimize the attack surface. Revisions help to reduce the likelihood of accidentally enabling a previous, obsolete iteration of a service. Revisions also help you test a new revision’s security posture using A/B testing along with monitoring and logging tools.	Infrastructure as code (IaC) to manage cloud resourcesCloud resources monitoring using Security Command CenterCloud Billing monitoringCleanup of unused cloud resources to minimize attack surface
12. Cross-execution data persistency	None	None

What’s next

• For a baseline secure environment, review the Google Cloud security foundations blueprint.
• To see the details of the blueprint that’s described in this document, read the Terraform configuration README file.
• To read about security and compliance best practices, see Google Cloud Architecture Framework: Security, privacy, and compliance.
• For more best practices and blueprints, see the security best practices center.

---

Reference: https://github.com/GoogleCloudPlatform/terraform-google-cloud-run

Terraform Cloud Run Module

This module handles the basic deployment of containerized applications on Cloud Run, along with domain mapping and IAM policy for the service.

The resources/services/activations/deletions that this module will create/trigger are:

• Creates a Cloud Run service with provided name and container
• Creates Domain mapping for the deployed service
• Applies Cloud Run Invoker role to members

Mapping custom domains and subdomains

You can map multiple custom domains and subdomains to the same Cloud Run service. If you want to register a domain with Cloud Domains, see Registering a domain with Cloud Domains within the Cloud Run console.

To add a custom domain or subdomain to your Cloud Run service, you need to add the values to the verified_domain_name variable.

Before you’ve mapped your service to a custom domain in Cloud Run, you need to update your DNS records at your domain registry. If you’re using Cloud DNS as your DNS provider, see Adding a record.

In case your DNS is not managed by Google Cloud Domains, the ownership of your domain needs to be verified adding a txt record on your DNS configuration. This verification can be done following the steps from this documentation.

Assumptions and Prerequisites

This module assumes that below mentioned prerequisites are in place before consuming the module.

• All required APIs are enabled in the GCP Project
• Cloud SQL (optional)
• VPC Connector (optional)
• Environment Variables in Secret Manager (optional)

Usage

Basic usage of this module is as follows:

module "cloud_run" {
  source  = "GoogleCloudPlatform/cloud-run/google"
  version = "~> 0.2.0"

  # Required variables
  service_name           = "<SERVICE NAME>"
  project_id             = "<PROJECT ID>"
  location               = "<LOCATION>"
  image                  = "gcr.io/cloudrun/hello"
}

Inputs

Name	Description	Type	Default	Required
argument	Arguments passed to the ENTRYPOINT command, include these only if image entrypoint needs arguments	list(string)	[]	no
certificate_mode	The mode of the certificate (NONE or AUTOMATIC)	string	"NONE"	no
container_command	Leave blank to use the ENTRYPOINT command defined in the container image, include these only if image entrypoint should be overwritten	list(string)	[]	no
container_concurrency	Concurrent request limits to the service	number	null	no
domain_map_annotations	Annotations to the domain map	map(string)	{}	no
domain_map_labels	A set of key/value label pairs to assign to the Domain mapping	map(string)	{}	no
encryption_key	CMEK encryption key self-link expected in the format projects/PROJECT/locations/LOCATION/keyRings/KEY-RING/cryptoKeys/CRYPTO-KEY.	string	null	no
env_secret_vars	[Beta] Environment variables (Secret Manager)	list(object({ name = string value_from = set(object({ secret_key_ref = map(string) })) }))	[]	no
env_vars	Environment variables (cleartext)	list(object({ value = string name = string }))	[]	no
force_override	Option to force override existing mapping	bool	false	no
generate_revision_name	Option to enable revision name generation	bool	true	no
image	GCR hosted image URL to deploy	string	n/a	yes
limits	Resource limits to the container	map(string)	null	no
location	Cloud Run service deployment location	string	n/a	yes
members	Users/SAs to be given invoker access to the service	list(string)	[]	no
ports	Port which the container listens to (http1 or h2c)	object({ name = string port = number })	{ “name”: “http1”, “port”: 8080 }	no
project_id	The project ID to deploy to	string	n/a	yes
requests	Resource requests to the container	map(string)	{}	no
service_account_email	Service Account email needed for the service	string	""	no
service_annotations	Annotations to the service. Acceptable values all, internal, internal-and-cloud-load-balancing	map(string)	{ “run.googleapis.com/ingress”: “all” }	no
service_labels	A set of key/value label pairs to assign to the service	map(string)	{}	no
service_name	The name of the Cloud Run service to create	string	n/a	yes
template_annotations	Annotations to the container metadata including VPC Connector and SQL. See more details	map(string)	{ “autoscaling.knative.dev/maxScale”: 2, “autoscaling.knative.dev/minScale”: 1, “generated-by”: “terraform”, “run.googleapis.com/client-name”: “terraform” }	no
template_labels	A set of key/value label pairs to assign to the container metadata	map(string)	{}	no
timeout_seconds	Timeout for each request	number	120	no
traffic_split	Managing traffic routing to the service	list(object({ latest_revision = bool percent = number revision_name = string tag = string }))	[ { “latest_revision”: true, “percent”: 100, “revision_name”: “v1-0-0”, “tag”: null } ]	no
verified_domain_name	List of Custom Domain Name	list(string)	[]	no
volume_mounts	[Beta] Volume Mounts to be attached to the container (when using secret)	list(object({ mount_path = string name = string }))	[]	no
volumes	[Beta] Volumes needed for environment variables (when using secret)	list(object({ name = string secret = set(object({ secret_name = string items = map(string) })) }))	[]	no

Outputs

Name	Description
domain_map_id	Unique Identifier for the created domain map
domain_map_status	Status of Domain mapping
location	Location in which the Cloud Run service was created
project_id	Google Cloud project in which the service was created
revision	Deployed revision for the service
service_id	Unique Identifier for the created service
service_name	Name of the created service
service_status	Status of the created service
service_url	The URL on which the deployed service is available
verified_domain_name	List of Custom Domain Name

Requirements

These sections describe requirements for using this module.

Software

• Terraform ~> v0.13+
• Terraform Provider for GCP >= 3.53, < 5.0
• Terraform Provider for GCP Beta >= 3.53, < 5.0

Service Account

A service account can be used with required roles to execute this module:

• Cloud Run Admin: roles/run.admin

Know more about Cloud Run Deployment Permissions.

The Project Factory module and the IAM module may be used in combination to provision a service account with the necessary roles applied.

APIs

A project with the following APIs enabled must be used to host the main resource of this module:

• Google Cloud Run: run.googleapis.com
• Serverless VPC Access (optional): vpcaccess.googleapis.com
• Cloud SQL (optional): sqladmin.googleapis.com