LORIN PRICE: My name is Lorin Price,
and I'm a Networking Specialist Customer
Engineer at Google Cloud.
And today, I'm going to talk to you about the networking
concepts for Cloud Run that are helpful to know
for implementation, security, and connectivity.
[MUSIC PLAYING]
Cloud Run is a managed compute platform
that enables you to run containers
that are invocable via requests or events.
Cloud Run is serverless.
It abstracts away all infrastructure management
so you can focus on what matters most--
building great applications.
Cloud Run, along with other Google Cloud serverless
services, does not run within a VPC.
Cloud Run is a regional service, meaning services
are deployed to a single region but replicated across zones
for high availability.
Let's dig into the connectivity patterns.
For the connectivity patterns, we're
going to focus on ingress and egress.
We'll start with ingress.
By default, when you deploy to Cloud Run,
you're given a URL that could be routed on the internet.
The URL will always be resolvable
on the public internet.
However, by default, services refuse all requests
unless IAM is configured for the service.
Ingress configuration and authentication parameters
can be set to change access patterns.
We'll dig more into these settings
when we talk about security.
The next ingress pattern is through a global external HTTPS
load balancer.
Cloud Run can be configured as a backend service
to a load balancer through a serverless Network Endpoint
Group, or NEG for short.
Additionally, with this option, you
have the ability to configure a custom domain for your Cloud
Run service.
Cloud Run services can be accessed privately
from your VPC through the use of Private Google Access
or Private Service Connect.
When PGA or PSC is used, rather than clients
needing an external IP address or using a NAT
gateway to egress to the internet,
clients can route privately to the Cloud Run service using
either a Google-provided VIP for PGA
or a chosen RFC 1918 endpoint for PSC directly from your VPC.
Private Google Access or Private Service Connect
can also be configured so that clients on-prem can connect
privately over a hybrid connection
to access a Cloud Run service.
Finally, there are a few scenarios
that can occur when another Google Cloud service needs
to send requests to Cloud Run.
Requests from Eventarc, Pub/Sub, and workflows
in the same project or VPC Service Control perimeter
are recognized as internal and can access Cloud Run directly
if the ingress is set to internal.
Requests from another Cloud Run service, App Engine,
and Cloud Functions in the same project or VPC Service Controls
perimeter are recognized as internal only
with the use of a serverless VPC access connector,
which we'll talk more about later.
Requests from other Google Cloud Services not mentioned cannot
use the internal ingress setting and must use service-specific
authentication.
However, Google Cloud is continuing
to update the list of services that
are recognized as internal.
Now let's move on to egress patterns.
By default, the Cloud Run service
connects to external endpoints on the internet
using a dynamic IP address pool, meaning
Cloud Run can egress directly from the application
if the destination is on the internet or public connectivity
is desired.
But what if the destination is within the VPC
and requires private connectivity?
This is where you can use a serverless VPC access
connector.
Requests originating from Cloud Run
can connect to sources in the VPC
using a serverless VPC access connector.
And the source of the requests would
appear as if they are originating from the connector.
Configuring a serverless VPC access connector
for a standard VPC is a simple process
of defining the access connector for a VPC
and choosing the subnet in which the connector will run.
There are two different configuration options
for a serverless VPC access connector for a shared VPC.
You can either set up connectors in each service project
that has Cloud Run resources that need access
to your network, or you can set up shared connectors
in the host project.
There are advantages to each method,
and you can check out the docs linked below
for more information.
The last egress pattern is through a static outbound IP.
As stated before, Cloud Run services
connect to endpoints on the internet using a dynamic IP
address pool.
But what happens if you need a single static IP
address in the event you need to connect to a database or API
using an IP address-based firewall?
With the use of the previously described serverless VPC access
connector, you can route outbound calls
through the VPC, which can then make
use of a Cloud NAT configured with a static address to egress
through the VPC with a predefined single IP address.
Now that we've discussed routing patterns,
let's talk about a few ways to secure Cloud Run services.
Make sure to properly configure your ingress and authentication
settings.
Ingress has the settings to allow all, allow
internal and load balancer, and allow internal traffic only.
As for authentication, you can choose
to allow unauthenticated invocations for public APIs
or websites or to require authentication for which users
are managed through Cloud IAM.
Additionally, if you are using an external HTTPS load
balancer, you can configure identity aware proxy, which
as of the date of publication, is
in preview as an authentication service
as well as Cloud Armor as a web application firewall.
So let's summarize the three most important takeaways
from today.
Cloud Run is serverless and does not run within a VPC.
Make sure you understand fully the ingress and egress patterns
of your service to know if you need to set up a serverless VPC
access connector to connect to applications and services
running within the VPC.
Set the appropriate ingress control
and authentication settings for the Cloud Run service.
Thanks for watching, and look out
for another video on the concepts of networking
for Google Cloud's managed services.