Connecting to Cloud SQL - Thinking about it

Hi friends!

So, You’ve created your first Cloud SQL instance! But the guide tells you to just connect to it in the cloud shell. Which is awesome. Don’t get me wrong. I LOVE the cloud shell. However, that does you virtually no good when trying to figure out how to connect to your database with your application, or database management tools.

What I’m going to cover in this post is the Where, How and Why of connecting to Cloud SQL.

1. Where you’re connecting from and how that affects what the docs call “public vs. private” IP and the considerations around that and how to set those up (spoiler alert, it’s not as simple as public vs. private).
2. How you connect. Specifically: Decisions to be made around type of authentication, using SSL or not. Whether or not using Google’s SQL proxy makes sense (What’s the proxy? Simplest terms, it’s a separate binary that enables secure connection to your Cloud SQL instance without worrying about allowlists of IP addresses, or manually configure SSL. More here.), or if it’s better to directly connect via the APIs.
3. Why will be some scenarios around when to combine different pieces of Where and How.

Where

When you setup your Cloud SQL instance, hidden under the configuration options in the Set connectivity dropdown, are the options for public and private IP setup.

I’m going to make a statement to keep in your head, then explain it in a bit more detail: Private means you’re connecting to Cloud SQL from inside the Virtual Private Cloud (VPC). Public means you’re connecting to it from the public internet.

So first, what’s a VPC?

There’s a detailed overview here. Short version: A VPC is a dedicated, private network similar to, say, the network in a corporate office, so that the different Google Cloud products can talk to each other without going out to the public internet.

There’s a lot of complicated networking uses for them. For now, just know that a default one exists (appropriately named “default”). If you decide to enable a private IP, you will see it listed in the configuration options under “Associated networking” (even if you haven’t set one up yourself). Note here, if you have a Legacy VPC because your project is a bit on the older side, it will not show up in the dropdown. You can check this by going to your VPC networks in the console and check the Mode of your default VPC.

If it’s Legacy it won’t show up as an option for your Cloud SQL instance.

Now here’s where it gets a bit complicated. Not all of Google Cloud’s products support VPC connectivity. In fact, some “serverless” products (like App Engine, Cloud Functions, or Cloud Run) aren’t able to connect to a VPC directly. It’s okay though, don’t panic. We have a workaround for that. The Serverless VPC Connector can grant your serverless environments access to products on your VPC (like a Cloud SQL instance with a private IP).

So quick recap: Public IP means potentially routing over the outside internet, private IP means from within a VPC network. Some GCP products require a bit of help to be able to use the private IP.

How

There are different ways you can connect to a Cloud SQL instance:

1. The Cloud Proxy
2. Public IP with allowlisted IPs of consumers
3. Private IP from VPC connected applications
4. Language-specific connectors (e.g. JDBC socket factory for Java)
5. Writing your own connector using API calls for ephemeral SSL creation/connection
6. Setting up SSL encryption with permanent key pairs

This is definitely a mix and match situation. You could, for example, connect to the Public IP as a whitelisted consumer, yet also have setup SSL encryption on the instance. We’ll get to why you would choose to do different configurations in the next section, but first I want to simply walk through how to setup some of the methods and highlight some use cases.

Most of what I’ve got will be incorporated into quickstarts on the official docs pages. So as they get incorporated, I’ll link to the quickstart instead of my quickblog. Links to the guides:

1. Private IP + Proxy (Google Compute Engine VM)
2. Public IP + Proxy
3. Public IP with allowlisted IPs
4. Proxy in a Kubernetes sidecar container

I’m also happy to add more to these initial ones. If you have specific ones you’d like to see, please add in a comment below, or reach out to me on Twitter (DMs open) and let me know.

Why

While you can connect to Cloud SQL in any of the ways we listed above, thinking about why you would pick which way really comes down to two things:

One, what your environment allows for. As we’ve mentioned, for example, if you’re working in an enterprise environment that won’t let you run extra binaries for any reason no way no how, then running Google’s SQL proxy won’t be an option and you’ll need to look to other options. Sometimes you might be in a situation where you need to be using permanent SSL certificates signed in a specific way. If the product stack you’re using in GCP doesn’t fully support VPC connectivity yet, then you’ll need to use a public IP instead of the private IP.

Two, risk tolerance. You could go the easiest to set up route, which is to just open up a public IP to your instance, and allowlist any IPs that are connecting. Please. Please. Don’t do that. MAYBE for testing purposes for your application, but in production, just don’t do that. Unless you don’t mind people having access to your database. In which case, by all means!

On the flipside, you can go all the way the other direction, and run your application on GCE within the same VPC as your Cloud SQL instance, so you can use the internal IP address, and then use Google’s SQL proxy alongside your application on localhost isolated so only your application can talk to the proxy.

Performance-wise, the differences between running in fully secure lockdown mode is likely to be a minuscule difference as compared to things like query optimization, but it IS greater than zero. Of course, if your application is dependent upon real-time responsiveness, then optimize for all the things. I’m just throwing a word of caution to not pre-optimize where you don’t need to. Don’t sacrifice data security for an extra few milliseconds of latency unless you need it.

Best practice is to use the Google SQL proxy. From a secure standpoint, it’s going to manage all the application to database instance encryption for you using ephemeral SSL tokens so even if one gets compromised, it’s a short-lived cert so your window of exposure is small. I’ll say it again for emphasis…unless you have requirements that keep you from using it, then use the proxy!

Conclusion

So there you have it! A hopefully mostly complete blog about connectivity around Cloud SQL on Google Cloud Platform. Wherever you connect from, however you choose to connect, I hope this blog helped you make it easy!

If you have any questions or comments, please leave ’em below, or reach out to me on Twitter. DMs are open!