LORIN PRICE: My name is Lorin Price.
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 SQL that are helpful to know
for implementation, security, and connectivity.
[MUSIC PLAYING]
Cloud SQL provides a managed service for MySQL, PostgreSQL,
and SQL Server databases.
Cloud SQL offers many services like backups,
high availability, maintenance, and more,
and all managed by Google Cloud.
Each Cloud SQL instance is powered by a virtual machine
running in a Google-managed environment that
is connected to the environment that you own and manage.
By running in a Google-managed environment,
this allows Cloud SQL to abstract away
all of the management overhead to be offloaded from you,
the user, to Google Cloud.
Even though Cloud SQL sits in a Google-managed environment,
Google will never have access to the data that resides
on the Cloud SQL instance.
Cloud SQL can be deployed with two different access patterns,
public IP and private IP.
Let's start by taking a look into the public IP deployment
pattern.
A public IP is an IPv4 address that
can receive connections from devices both inside and outside
of Google's network, including from locations like your home
or office.
Let's take a look at the access patterns
from different scenarios.
Let's say you want to connect from a client on prem.
To connect to a Cloud SQL instance,
the traffic will egress from your on-prem network
and access Cloud SQL through a public IP
address on the internet.
If a client is located in Google Cloud,
the traffic will egress through an instance with a public IP
address or a Cloud NAT and ingress to the Cloud SQL
instance through its public IP address.
If the client is located somewhere on the internet,
that client can access the Cloud SQL instance directly
through its public IP.
Any clients making a connection to a Cloud SQL instance
hosted with a public IP must be allow
listed through the use of authorized networks.
By default, the allow list is empty,
and nothing can make connections to the Cloud SQL instance.
Clients can also connect to a Cloud SQL instance
hosted with a public IP through a Cloud SQL auth
proxy, which we'll discuss more later in this video.
The other Cloud SQL deployment pattern is through private IP.
A private IP is an IPv4 that's accessible on a Virtual Private
Cloud, or VPC.
Configuring your instance with a private IP
is preferred when connecting from a client with access
to a VPC, either within the VPC or connected to the VPC
through a hybrid connection.
Private IP Cloud SQL is deployed using Private Service Access.
Private Service Access is a commonly used private
routing method on Google Cloud that
allows workloads in your VPC to access
Google-managed infrastructure services privately.
Private Service Access is implemented
as a VPC peering connection between your VPC network
and the underlying Google Cloud VPC network where your Cloud
SQL instance resides.
There are two parts to the Private Service Access
configuration process.
You will start by selecting an existing
or allocating a new IP address range as the Private Service
Access range.
You also have the option of allowing Google
to allocate the range for you.
In this case, Google will automatically allocate an IP
range of prefix length /20 and use the name default IP range.
If you're going to create instances in multiple regions
for different database types, a /20 or larger range is
recommended.
Next, a private connection, otherwise known as VPC peer,
will be created from your VPC network
to the underlying service producer network.
Keep in mind that you only need to configure Private Service
Access once for Cloud SQL per VPC network.
And the IP range you allocate for Private Service Access will
become available for use by all Google services
globally that support Private Service Access.
Let's talk through the access patterns.
Let's start with a client attempting to access the Cloud
SQL instance from the internet.
Because Cloud SQL is deployed on a private IP,
there's no way for public clients
to access the instance directly.
Now let's walk through a connection
initiated from within the VPC and Google Cloud.
Clients are able to connect directly
to the Cloud SQL instance from the directly peered VPC.
Additionally, you can also use the Cloud SQL auth proxy.
If you are in a peered hub and spoke architecture model,
and you're trying to make a connection from a VPC that
is not directly paired to the Private Service Access VPC,
you must use a proxy due to the nontransitive
routing nature of Google's VPCs.
Be aware you can also replace a peering hub
and spoke architecture with a VPN hub
and spoke model, so that the Private Service Access route
can be advertised over the VPN.
Finally, for a client to connect from on prem,
you'll need to make sure you're advertising the Private Service
Access route over the VPN or the Interconnect.
If the VLAN or VPN lands in the VPC that is peered directly
with the Private Service Access VPC,
then you'll be able to connect directly.
If the VLAN or VPN lands in another peered VPC, then
you'll need to use a proxy to connect.
Remember, you'll never be able to ping a Cloud SQL instance.
You'll only be able to initiate connections
through applications, the respective database
client, or the Cloud SQL proxy.
Let's quickly touch on some network
security-related topics.
For Cloud SQL deployed with public IP,
you can use authorized networks to determine
a list of whitelisted IP addresses
that can access your instance.
You cannot use firewall rules to control ingress to a Cloud SQL
instance.
You can use the Cloud SQL auth proxy
to encrypt all traffic to and from the database using TLS
and to control who and what can connect to your Cloud SQL
instance.
So let's summarize the three most important takeaways
from today.
Cloud SQL can be deployed with either a public IP
or private IP access pattern.
If you want to use Cloud SQL private IP,
you must create a Private Service Access IP range,
and a VPC peer will be created.
Remember this when it comes to routing.
You can use authorized networks or Cloud SQL auth proxy
to determine who and what can access the Cloud SQL instance.
Thanks for watching, and look out
for another video on the concepts of networking
for Google Cloud's managed services.
[MUSIC PLAYING]