You can send HTTPS requests from anything able to make HTTPS requests to trigger a Cloud Run-hosted service. Note that all Cloud Run services have a stable HTTPS URL.
Some of the use cases include:
- Custom RESTful web API
- Private microservice
- HTTP middleware or reverse proxy for your web applications
- Pre-packaged web application
Creating public services
Creating a public service on Cloud Run requires:
- Access to the service from the public internet
- A URL intended for public use
To make a service public, set your service to allow unauthenticated (public) access when you deploy, or at any time after you deploy.
You can use the stable, auto-assigned URL provided on the first deployment of your service as the public URL on Cloud Run. To determine the URL of a deployed service:
gcloud run services describe SERVICE --format 'value(status.url)'
The URL for a Cloud Run service has the format
https://[
TAG---]
SERVICE_IDENTIFIER.run.app
,
where TAG refers to the traffic tag for the revision that you
are requesting, and SERVICE_IDENTIFIER is a stable and unique
identifier for a Cloud Run service. Do not parse the
SERVICE_IDENTIFIER as it does not have a fixed format, and the
logic for SERVICE_IDENTIFIER generation is subject to change.
You can also use your own custom domain that maps to the service. This automatically provides managed SSL certificates.
Cloud Run redirects all HTTP requests to HTTPS but terminates
TLS before they reach your web service. If your service generates a web resources
that refers to other web resources with unsecured URLs (http://
), your page may
be subject to mixed content warnings or errors.
Use the https
protocol for all reference web URIs or account
for proxy directives in the HTTP Request such as the X-Forwarded-Proto
HTTP header.
HTTP and HTTP/2
By default, Cloud Run downgrades HTTP/2 requests to HTTP/1 when those requests are sent to the container. If you want to explicitly set your service to use HTTP/2 end-to-end, refer to Using HTTP/2.
Creating private services
Creating a private service on Cloud Run requires you to limit access to the service.
You can limit access to your service using IAM as discussed in Managing access using IAM.
The easiest way for developers to test private services is to use a tool
like curl
and pass an auth token in the Authorization
header:
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" SERVICE_URL
Note that a Cloud Run service can call another Cloud Run service with service-to-service authentication.
In addition to the above listed ways to limit access, you can also limit access to a service using application-level authorization and authentication mechanism, for example, using Identity Platform.
Sample code that invokes HTTP requests
For code samples that shows how to obtain an ID token and make an HTTP request to a private service, refer to the topic Authenticating service-to-service.
Using a middleware to enhance your service
HTTPS proxies can offload common functionality from an HTTP service, such as caching, request validation, or authorization. For microservices, many HTTP proxies are part of an API Gateway solution or a service mesh such as Istio.
Google Cloud products that you can use to enhance your Cloud Run service include:
API Gateway, which you can use to create, secure, and monitor APIs to use as proxies to other Cloud Run services.
Firebase Hosting, which you can use to build a web application frontend to use with Cloud Run as a dynamic backend.