Motivation

Our organization uses GCP’s Cloud SQL service to host our relational databases. A challenge we had was determining how to ensure that no un-authenticated traffic can access the database, while at the same time allowing developers who need access to the database the ability to easily view needed tables.

In terms of compute resources that rely on the Cloud SQL DBs, our APIs running in GCP’s Cloud Run service would also require access to these databases.

Furthermore, we wanted to implement the simplest, least expensive option available to us.

Initial Approach: VPC + VPN

We initially explored placing our DB within our VPC with only a private endpoint, creating an organization-wide VPN that can access the VPC, and then providing access to our Cloud Run instances via a Serverless VPC Access Connector.

We identified some VPN providers, and after building out the GCP resources to support this solution realized that although this route is sometimes viewed as “canonical”, it was burdening us with some potentially avoidable costs:

• Getting a VPN with a dedicated Server IP costs ~$480 / year, + $108 / developer from a service like NordLayer.
• For a development team like ours without a significant networking background, the cost of setting the service up and maintaining it is not trivial.
• Least importantly, but still worth noting, introducing a VPN is another tool that new team members require provisioned access to.

New Approach: Locked-down Public IP with Google Cloud Proxy

After some more research, we realized we could accomplish our goals less expensively, with no additional cloud infrastructure, and a self-serve onboarding process.

The solution we settled on was to provision a public endpoint for our database instances, but allow no external networks to access the instance. We then have encrypted DB access through Google’s Cloud SQL Proxy Client for users that have the requisite IAM permissions.

Now, our developers who need access to the databases, can do the following:

1. Run: gcloud auth login
2. Run: gcloud auth application-default login
3. Download the Cloud SQL Proxy Client
4. Run: PATH/TO/YOUR/EXECUTABLE/cloud_sql_proxy.exe -instances=your_connection_name=tcp:3306

Some comments: Chances are that they have already run steps one and two previously. Lastly, the port depends on your DB type, with 3306 for MySQL and 5432 for Postgresql.

JetBrains has an excellent guide for following these steps to connect to Cloud SQL via their DataGrip tool.

For our Cloud Run Instance, connecting to the Cloud SQL instance is as straightforward as adding the DB of interest to the “Cloud SQL Connections” line in the instance’s configuration. Google has good documentation explaining how this connection works for those curious.

But isn’t this less secure than the VPC approach?

This is a question that should not be brushed aside, given that databases store business critical information.

It helps to do a side by side comparison: