This page describes how to use ingress settings to restrict network access to your
Cloud Run service. At a network level, by default, any resource on the
internet is able to reach your Cloud Run service on its
run.app
URL or at a custom domain set up in Cloud Run. You can change
this default by specifying a different setting for ingress. All ingress paths,
including the default run.app
URL, are subject to your ingress setting.
Ingress is set at the service level.
Ingress settings and IAM authentication methods are two ways of managing access to a service. They are independent of each other. For a layered approach to managing access, use both.
Available ingress settings
The following settings are available:
Setting | Description |
---|---|
Internal |
Most restrictive. Allows requests from the following sources:
run.app URL. Requests
from other sources, including the internet, cannot reach your service at
the run.app URL or custom domains.Requests to Cloud Run from Cloud Run, Cloud Functions, or App Engine must go to the VPC network to be considered internal. To route requests to the VPC network, use Direct VPC egress or a Serverless VPC Access connector and enable Private Google Access on the subnet associated with Direct VPC egress or the connector. There is no support for multi-tenancy, that is, multiple trust domains within the same project. |
Internal and Cloud Load Balancing | Allows requests from the following resources:
|
All |
Least restrictive. Allows all requests, including requests directly from
the internet to the run.app URL.
|
Accessing internal services
The following additional considerations apply:
When accessing internal services, call them as you would normally do using their public URLs, either the default
run.app
URL or a custom domain set up in Cloud Run.For requests from Compute Engine VM instances, no further setup is required for machines that have public IP addresses or that use Cloud NAT. Otherwise, see Receive requests from VPC networks.
For requests from other Cloud Run services or from Cloud Functions in the same project, connect the service or function to a VPC network and route all egress through the connector, as described in VPC with connectors. Note that the IAM invoker permission is still enforced.
Requests from resources within VPC networks in the same project are classified as "internal" even if the resource they originate from has a public IP address.
Requests from resources in a separate project but within the same VPC Service Controls perimeter can only call an internal service if you configure the Cloud Run Admin API as a restricted service in the service perimeter.
For information about when Shared VPC traffic is recognized as "internal", see Special considerations for Shared VPC.
Requests from on-premises resources connected to the VPC network via Cloud VPN and Cloud Interconnect are considered "internal".
For requests from Cloud Scheduler, Cloud Tasks, Eventarc, Pub/Sub, BigQuery, and Workflows to an internal service, the following considerations apply:
- You must use the Cloud Run default
run.app
URL for that service, not any custom domain. - The job, task, Pub/Sub subscription, event, workflow, or BigQuery remote function must be in the same project or VPC Service Controls perimeter as the Cloud Run service.
- You must use the Cloud Run default
You can call internal services from traffic sources outside of the VPC network by using Cloud Scheduler, Cloud Tasks, Pub/Sub, Eventarc, Workflows, or BigQuery from within the same project or VPC Service Controls perimeter.
Setting ingress
You can set ingress using any of the supported methods in the tabs:
Console
If you are configuring a new service, click Create Service and fill out the initial service settings page as desired.
If you are configuring an existing service, click on the service, and then click the Networking tab.
Select the ingress traffic you want to allow:
Click Create or Save.
Command line
If you are deploying a new service, deploy your service with the
--ingress
flag:gcloud run deploy SERVICE --image IMAGE_URL --ingress INGRESS
Replace
INGRESS
with one of the available ingress settings:all
internal
internal-and-cloud-load-balancing
SERVICE
with your service name- IMAGE_URL with a reference to the container image, for
example,
us-docker.pkg.dev/cloudrun/container/hello:latest
. If you use Artifact Registry, the repository REPO_NAME must already be created. The URL has the shapeLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
If you are changing an existing service ingress:
gcloud run services update SERVICE --ingress INGRESS
Replace
INGRESS
with one of the available ingress settings:all
internal
internal-and-cloud-load-balancing
SERVICE
with your service name
YAML
If you are creating a new service, skip this step. If you are updating an existing service, download its YAML configuration:
gcloud run services describe SERVICE --format export > service.yaml
Update the
run.googleapis.com/ingress:
annotation:apiVersion: serving.knative.dev/v1 kind: Service metadata: annotations: run.googleapis.com/ingress: INGRESS name: SERVICE spec: template: metadata: name: REVISION
Replace
- SERVICE with the name of your Cloud Run
- INGRESS with one of the
available ingress settings:
all
internal
internal-and-cloud-load-balancing
- REVISION with a new revision name or delete it (if present). If you supply a new revision name, it must meet the following criteria:
- Starts with
SERVICE-
- Contains only lowercase letters, numbers and
-
- Does not end with a
-
- Does not exceed 63 characters
- Starts with
Replace the service with its new configuration using the following command:
gcloud run services replace service.yaml
Terraform
To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.
Add the following to your main.tf
file:
What's next
- Learn about egress settings
- Set up an internal Application Load Balancer for Cloud Run
- Set up an external Application Load Balancer with Cloud Run
- Configure IAM authentication methods for accessing services