Security design overview

Learn how Cloud Run implements security best practices to protect your data across services, jobs, worker pools, and instances, and explore how to use these features to meet your security requirements.

Architecture

Cloud Run runs on top of Borg in the same environment where Google deploys billions of containers a week, hosting some of the biggest sites in the world, including Gmail and YouTube. Because Cloud Run components share the same infrastructure, they are built to the same security standards as other Google services.

To learn more about our approach to security, read the Google security overview whitepaper.

The Cloud Run resource model includes services, jobs, worker pools, and instances (Preview) that share this underlying infrastructure.

The Cloud Run architecture contains many different infrastructure components. The following diagram shows how these components respond to requests and network traffic to your workload and Cloud Run Admin API calls:

Illustration of Cloud Run infrastructure components
Figure 1. Diagram of Cloud Run infrastructure components.

Requests and network traffic to your workload

When a request is made to your Cloud Run service or instance (either through your custom domain or directly to your run.app URL), or when transport layer 4 (TCP and UDP) traffic is sent over a Virtual Private Cloud (VPC) network to a worker pool or instance using Direct VPC ingress, the traffic and the underlying container runtime are handled by the following components. Cloud Run jobs and worker pools don't have a run.app URL or use the HTTP proxy, though they share the same scheduling, sandboxing, storage, metadata, and outbound networking components:

  • The Google Front End (GFE) is the Google global infrastructure service that terminates TLS connections and applies protections against DoS attacks when you make a request to the run.app URL. Cloud Run is a regional service, so when a request is accessed through the run.app URL, the GFE forwards the request to Cloud Run through an encrypted channel in the appropriate region.
  • A Google Cloud load balancer includes the GFE functionality mentioned previously when you set up Cloud Load Balancing to handle your custom domain. You can also configure Google Cloud load balancers to perform additional functions, such as traffic management and access control.
  • The HTTP proxy is a zonal component that load balances incoming HTTP requests to the instances of your sandboxed services and instances.
  • Direct VPC ingress routes transport layer 4 (TCP and UDP) traffic directly from your VPC network to the private IP addresses of your worker pool or Cloud Run instances without passing through the GFE or HTTP proxy.
  • The scheduler selects the app servers to host instances of your sandboxed services, jobs, worker pools, and instances.
  • The app server is a zonal and multi-tenant compute node that creates and manages the sandboxes that run the instances of each workload's container.
  • The sandbox isolates user code from the system and other customers. Learn more in the Compute security section.
  • Storage exposes a file server interface for container images imported from supported container registries and mounted volumes.
  • The metadata server provides sandbox-specific credentials and instance metadata, including the instance's ephemeral Direct VPC private IP address.
  • Outbound networking manages outbound traffic initiated by the sandbox.

Cloud Run Admin API calls

When a request is made to the Cloud Run Admin API to create, update, or manage services, jobs, worker pools, or instances, the request is handled by the following components:

  • The Google Front End (GFE) terminates TLS connections and applies protections against DoS attacks.
  • The control plane validates and writes your resource configurations to storage.
  • Config storage stores resource configurations in Spanner and Bigtable for access by other components, such as the app server, scheduler, and networking elements.

Compute security

An instance is defined as the unit where your configured containers run across Cloud Run services, jobs, worker pools, and standalone Cloud Run instances. When you deploy a single container image, each instance runs a single container. When you deploy multiple container images (sidecars), each instance contains the set of containers.

Each Cloud Run instance is protected (sandboxed) from every other by a boundary enforced by a virtual machine monitor (VMM). While we do provide some degree of container boundary enforcement, it's not as strong as the instance boundary around your container or containers.

Execution environments

Cloud Run components run on Google's container-management system, Borg. Cloud Run offers two execution environments:

  • The first generation execution environment is based on the gVisor container security platform. This option has a small codebase, which provides a smaller attack surface. Every change is security-reviewed and most changes are written in a memory-safe manner. Further hardening is achieved by using Secure Computing Mode (seccomp) system call filtering.
  • The second generation execution environment is based on Linux microVMs and provides more compatibility and performance for custom workloads. Further hardening is achieved by using seccomp system call filtering and Sandbox2 Linux namespaces.

Cloud Run services support both the first generation and second generation execution environments. Cloud Run jobs, worker pools, and instances run on the second generation execution environment.

Both of these execution environments use two layers of sandboxing consisting of a hardware-backed layer equivalent to individual VMs (x86 virtualization) and a software kernel layer, as shown in the following diagram:

In both execution environments, the user container is isolated from other workloads through two layers of sandboxing.
Figure 2. In both execution environments, the user container is isolated from other workloads through two layers of sandboxing.

If your service uses third-party infrastructure to secure containers, select the second generation execution environment. Jobs, worker pools, and instances use the second generation execution environment automatically.

Cloud Run sandboxes

For workloads that execute untrusted or AI-generated code (such as AI agent code execution or browser automation), you can enable Cloud Run sandboxes (Preview) on services, jobs, worker pools, and instances.

Cloud Run sandboxes run inside the same instance as the host container and share its CPU and memory allocation, while isolating untrusted code from the parent application. Each sandbox runs with a read-only root file system, has no access to the parent container's environment variables, mounted secrets, or metadata server credentials, and blocks outbound network egress by default.

For architectural guidance on isolating untrusted code across tenants, see Best practices for multi-tenant platforms running untrusted code on Cloud Run.

Cloud Run Threat Detection

To continuously monitor the state of your Cloud Run services, jobs, worker pools, and instances on the second generation execution environment for common runtime attacks, such as suspicious binaries or malicious code, use Cloud Run Threat Detection.

Vulnerability Assessment for Google Cloud

To continuously discover software package vulnerabilities (CVEs) and exposed secrets in container images in your running Cloud Run services, jobs, and worker pools, use Vulnerability Assessment for Google Cloud.

Data encryption and storage

Cloud Run container instances across services, jobs, worker pools, and instances are stateless. Container file systems use in-memory storage, and worker pools also support ephemeral disks (Preview) for temporary scratch storage. Terminating an instance discards its local state, so all new instances start from a clean slate.

If you have stateful data, you can manage your data in the following ways:

  • Store stateful data in external storage services, such as Cloud SQL or Memorystore.
  • Mount persistent volumes backed by Cloud Storage buckets or NFS file shares (such as Filestore) in your services, jobs, worker pools, and instances.
  • Integrate with Secret Manager to securely mount or expose sensitive data such as API keys and passwords in services, jobs, worker pools, and instances.

Beyond that, Cloud Run integrates with many other Google Cloud systems to manage and access your data in the following ways:

Across Google Cloud, all your data is encrypted at rest.

Cloud Run complies with Google Cloud-wide initiatives for data protection and transparency, including access transparency and data residency. For information about compliance standards and certifications, see Cloud Run regulatory compliance.

Network security

Cloud Run and all other Google Cloud services encrypt all traffic in transit. You can incorporate both egress and ingress controls into your Cloud Run services, jobs, worker pools, and instances to add an additional layer of restriction. Organization administrators can also enforce egress and ingress by setting organization policies.

Egress (outbound) traffic

Egress traffic that exits from Cloud Run services, jobs, worker pools, and instances is treated as transport layer 4 (TCP and UDP).

By default, egress traffic takes one of the following paths when exiting Cloud Run:

  • When the target destination is in a VPC network, traffic travels to a VPC network or Shared VPC network in your project by using Direct VPC egress (supported across services, jobs, worker pools, and instances) or a Serverless VPC Access connector. With Direct VPC egress, Cloud Run sends traffic directly to your VPC network without intermediate proxy VMs. A Serverless VPC Access connector is a regional resource that sits on the VPC network.
  • When the target destination is not in a VPC network, traffic routes directly to the target destination within Google's network or the public internet. Outbound connections to the public internet use a regional pool of dynamic IP addresses shared across Cloud Run and other serverless workloads.
Cloud Run networking path to VPC and non-VPC networks
Figure 3. Egress traffic can travel to a VPC or to a non-VPC network using Direct VPC egress or a connector.

Controlling egress

For additional control over egress traffic from services, jobs, worker pools, and instances, use the VPC egress setting to route all outbound traffic to your VPC network by using Direct VPC egress or a Serverless VPC Access connector.

Once traffic is on the VPC network, you can use VPC tools to manage the traffic:

Organization administrators can also enforce egress by setting the Allowed VPC egress settings (Cloud Run) (constraints/run.allowedVPCEgress) list constraint.

Shared internet egress risks and acceptable use

By default, outbound traffic to the public internet uses a regional pool of dynamic IP addresses shared with other serverless workloads. Keep the following risks and responsibilities in mind:

  • Noisy or abusive traffic from another workload in the region can degrade the reputation of the shared IP address pool. External firewalls and third-party web application firewalls (WAFs) might throttle or block requests from these shared IP addresses, causing connection timeouts or HTTP 403 errors.
  • Don't use the default shared IP pool for reputation-sensitive external endpoints, such as payment gateways, hosted databases, or partner APIs behind WAFs. Instead, route all outbound traffic (--vpc-egress=all-traffic) through your VPC network and use Cloud NAT with dedicated static IP addresses.
  • Don't run network scanning, port enumeration, host fingerprinting, vulnerability probing, web scraping, or load testing over the default shared internet egress path. This activity degrades shared IP reputation, can disrupt service for other customers in violation of the Google Cloud Acceptable Use Policy, and might cause Google to throttle or suspend your workload.
  • If you run authorized security scanning, host fingerprinting, or load testing workloads, you must isolate your outbound traffic. Configure Direct VPC egress with --vpc-egress=all-traffic and route requests through Cloud NAT using your own static outbound IP addresses.

Ingress (inbound) traffic

How inbound traffic reaches Cloud Run depends on the resource type:

  • Cloud Run services and instances accept application layer 7 (HTTPS) requests through their default run.app URL, custom domains, or Cloud Load Balancing.
  • Cloud Run worker pools don't have a run.app URL or layer 7 HTTP ingress controls. When you connect a worker pool or a Cloud Run instance to a VPC network by using Direct VPC, each instance receives an ephemeral private IP address from the configured VPC subnet and can receive transport layer 4 (TCP and UDP) traffic directly from resources in that VPC network, subject to VPC firewall rules. You can retrieve the instance's private IP address from the metadata server. Note that Serverless VPC Access connectors don't support ingress traffic, and Direct VPC private IP addresses don't persist across instance stops, restarts, or updates.
  • Cloud Run jobs run to completion and don't accept inbound requests.

For layer 7 HTTP ingress, Cloud Run services and instances accept incoming traffic from the following sources:

Network ingress paths to Cloud Run from the internet, VPC, and Google Cloud services
Figure 4. Layer 7 HTTPS and layer 4 Direct VPC network ingress (inbound) traffic to Cloud Run.

Cloud Run's network security model includes the following layer 7 ingress traffic properties:

  • The default run.app URL always requires HTTPS for traffic to enter Cloud Run. Google's frontend-serving infrastructure terminates TLS and then forwards the traffic to Cloud Run and to your container through an encrypted channel. You can disable the default URL on services and instances.
  • For HTTPS traffic to a custom domain associated with your Google Cloud load balancer, Google Cloud internal and external load balancers terminate TLS and forward traffic to Cloud Run and your container through an encrypted channel. Google Cloud load balancers also let you apply additional security features such as Identity-Aware Proxy (IAP), Google Cloud Armor, and SSL policies.

For more information about configuring VPC network traffic to Cloud Run, see Receive requests from VPC networks and Receive requests from other Cloud Run resources or App Engine.

Controlling ingress

Cloud Run ingress controls manage what layer 7 traffic enters your Cloud Run services and instances to ensure that traffic comes only from trusted sources.

For Cloud Run services and instances that serve only internal clients, you can configure the "internal" setting so that only traffic from the following internal sources can enter Cloud Run:

  • VPC networks in your project or VPC Service Controls perimeter, including Cloud Run services, jobs, worker pools, and instances that route their outbound traffic through the VPC network by using Direct VPC egress or a Serverless VPC Access connector.
  • The Shared VPC network that the Cloud Run resource is attached to.
  • Some Google Cloud services, such as BigQuery, that are in your project or VPC Service Controls perimeter.
  • Traffic from on-premises clients that traverse your VPC network to reach Cloud Run.

If you are using an external or internal load balancer, or if your instance processes background workloads without serving HTTP traffic, you can disable the default run.app URL.

Organization administrators can also enforce ingress by setting the Allowed ingress settings (Cloud Run) (constraints/run.allowedIngress) organization policy.

For more information about controlling ingress, see Restricting ingress for Cloud Run.

Access control

Access controls restrict who can manage your Cloud Run services, jobs, worker pools, and instances, what those workloads can access, and who can invoke or execute them.

Who can manage your resources

To control who manages your Cloud Run services, jobs, worker pools, and instances, Cloud Run uses Identity and Access Management (IAM) to authorize users and service accounts.

Organization administrators can also create and enforce custom organization policy constraints on Cloud Run services, jobs, and worker pools to restrict how resources are configured when they are created or updated.

What your resources can access

To control what your Cloud Run services, jobs, worker pools, and instances can reach over the network, you can route outbound traffic through the VPC network and apply VPC firewall rules, as described in the Network security section.

If you're using Direct VPC egress on a service, job, worker pool, or instance, you can attach network tags directly to the Cloud Run resource and reference those network tags in VPC egress firewall rules (network tags on Cloud Run resources can't be used to define the target of an ingress firewall rule). If you're using Serverless VPC Access, you can apply firewall rules to the connector instances.

Use IAM to control what Google Cloud resources your Cloud Run workloads can access. By default, services, jobs, worker pools, and instances use the Compute Engine default service account. For production and sensitive workloads, configure a dedicated service identity on your services, jobs, worker pools, and instances so that you grant only the minimum permissions that each workload needs. For information about how Cloud Run identifies services that use the default service account, see Secure Cloud Run services with Recommender.

For AI agents deployed on Cloud Run services or jobs, you can also assign a system-managed Agent Identity (--identity-type=agent-identity, Preview) instead of a service account. See Secure AI agents and MCP servers for details.

Who can invoke or execute your resources

Cloud Run provides several options to control who invokes your service or instance, communicates with your worker pool, or executes your job.

Ingress controls

To manage layer 7 ingress for Cloud Run services and instances at the networking level, see Controlling ingress in the previous section.

For Cloud Run worker pools (and instances receiving layer 4 traffic over Direct VPC), use VPC firewall rules to control which sources in your VPC network can connect to the subnet IP range of your instances (network tags on Cloud Run resources aren't supported as targets for ingress firewall rules).

Cloud Run jobs don't serve requests and therefore don't use network ingress controls when executing jobs.

IAM for services and instances

Use the run.routes.invoke permission for services or the run.instances.invoke permission for instances to configure who can send HTTP requests to your workload:

  • Grant the permission (through the Cloud Run Invoker role, roles/run.invoker) to specific users, service accounts, agent identities, or groups to require authentication. All requests must include an HTTP Authorization header containing an OpenID Connect ID token or OAuth 2.0 access token signed by Google for an authorized principal. You can further restrict access by adding IAM Conditions to the role binding.
  • Select Allow public access (or pass --no-invoker-iam-check) to disable the Cloud Run Invoker IAM check and allow unauthenticated requests. When the Invoker IAM check is enabled, Cloud Run performs an IAM check on every request before forwarding it to your container.

To ensure that only members of your organization can invoke a Cloud Run service or instance, an organization administrator can configure the Domain restricted sharing (constraints/iam.allowedPolicyMemberDomains) constraint and the constraints/run.requireInvokerIam (or legacy constraints/run.managed.requireInvokerIam) constraint, which prevents disabling the Invoker IAM check.

Learn more about common use cases for authentication and how Cloud Run uses access control with IAM.

IAP for services

For Cloud Run services, you can enable IAP directly on the service to authenticate and authorize user traffic without requiring a load balancer. You can also use Workforce Identity Federation with IAP on Cloud Run services. Learn how to configure Identity-Aware Proxy for Cloud Run.

Load balancer security features

If you configure a Cloud Run service or instance as a backend to a Google Cloud load balancer, secure this path by using the following methods:

IAM for jobs

Use the run.jobs.run and run.jobs.runWithOverrides permissions to configure who can execute your Cloud Run job:

  • Grant the permission to specific service accounts or groups to allow access to the job. If the job is triggered by another service, such as Cloud Scheduler or Workflows, the service account used by that service must have the run.jobs.run permission on the job.
  • Grant the permission to users who need to execute the job from the Google Cloud console or the Google Cloud CLI.

To ensure that only members of your organization can execute a Cloud Run job, an organization administrator can set the Domain restricted sharing constraint. Organization administrators can also opt out specific Cloud Run jobs.

VPC Service Controls

Your Cloud Run services, jobs, worker pools, and instances can be part of a VPC Service Controls perimeter so that you can use VPC Service Controls to gate access and mitigate data exfiltration risk. Learn more about using VPC Service Controls.

Secure AI agents and MCP servers

When you deploy AI agents or Model Context Protocol (MCP) tool servers on Cloud Run, you can combine Cloud Run's compute isolation, network controls, and IAM authentication with dedicated agent security features:

  • Configure a system-managed Agent Identity (--identity-type=agent-identity, Preview) on your agent services or jobs (--functional-type=agent) to provision a dedicated, cryptographically verifiable identity (principal://...) with managed mTLS certificates instead of a shared service account. Declaring --functional-type=agent or --functional-type=mcp-server also registers your workloads in Agent Registry for centralized discovery and governance. See Configure agent platform features.
  • Authenticate agent-to-agent (A2A) and agent-to-MCP requests by requiring the Cloud Run Invoker role (roles/run.invoker) with unbound or mTLS certificate-bound OpenID Connect identity tokens. When an agent needs to call external tools or third-party APIs on behalf of an end user, use Auth Manager (Preview) to manage OAuth 2.0 user consent and credentials. See Authenticate AI agents.
  • Secure remote MCP servers hosted on Cloud Run by enforcing roles/run.invoker for automated workload-to-workload callers, or by enabling IAP (--iap with roles/iap.httpsResourceAccessor and custom OAuth clients) for interactive developer CLIs and desktop applications. See Authenticate MCP servers.
  • Isolate untrusted LLM-generated code execution (Code execution) and headless browser sessions (Browser automation) inside Cloud Run sandboxes so that untrusted code can't access the host agent's environment variables, mounted secrets, metadata server credentials, or outbound network.

Supply chain security

Cloud Run provides several features to help secure your software supply chain from source code to running containers.

Google Cloud's buildpacks-managed base images

Services, jobs, and worker pools that are deployed from source code using Google Cloud's buildpacks are built using Google-provided base images. Google maintains these base images and provides routine patches on a weekly basis. In emergency situations involving critical security vulnerabilities, we're able to make patches available within hours.

Cloud Run internal supply chain security

Because it runs on Borg, Cloud Run implements all of the same supply chain security that's standard across all Google services, such as Gmail and YouTube. Read more about Google internal supply chain practices in the BeyondProd and Binary Authorization for Borg whitepapers.

Binary Authorization

Cloud Run has built-in support for Binary Authorization across services, jobs, worker pools, and instances to ensure that only trusted container images are deployed on Cloud Run. Read more at Set up overview for Cloud Run.

Software supply chain security insights

Cloud administrators can view security information about the supply chain of their deployed revisions directly from a panel in the Google Cloud console. Read more at View software supply chain security insights.

Execution environment security

For Cloud Run services, automatic base image updates apply operating system and runtime security patches to compatible containers without rebuilding or redeploying your code. Cloud Run applies these updates with zero downtime by rebasing the container on an updated Google-maintained base image after stability testing, or within hours for critical security vulnerabilities.

Services deployed from source with Google Cloud's buildpacks are compatible with automatic base image updates. For jobs and worker pools deployed from source, redeploy the resource to pick up the latest base image patches.

To learn more, see Configure automatic base image updates.

What's next