Understanding Cloud SQL connectors

Connecting to a database can be one of the most challenging parts of setting up a new application. We know we aren’t the only developers who have lost full days to creating the right connection string followed by asking ourselves, “Should our database password be here in plain text?” (Hint: No)

Cloud SQL, Google Cloud Platform’s fully managed relational database service for MySQL, PostgreSQL, and SQL Server, makes connecting easy with the Cloud SQL connectors.

Life before connectors

In Google Cloud, you can create a new Cloud SQL database in minutes.

Now what? Typically the next step is to connect your application to the database. Of course, you also need to connect securely to protect your application’s critical data and ensure that all traffic across the network is encrypted.

In the traditional approach to connecting securely to a database, you’ll need to:

Provision SSL certificates

Make those certificates available to your application securely

Figure out how to rotate the SSL certificates regularly

Create database users and passwords

Figure out how to rotate the users’ passwords regularly

Set up firewall rules or Authorized Networks to allow only authorized applications to reach the database

Now you’re thinking, “Security is important, but what a pain!”

This is where Cloud SQL connectors come in to make life easy.

Enter Cloud SQL connectors

Cloud SQL connectors are utilities both in library and binary form that you ship with your application to ensure a secure connection to your database. Cloud SQL has connectors for Java, Python, Go, and NodeJS. If your application is written in one of those languages, we recommend starting with the language-specific connector. Otherwise, the Cloud SQL Auth proxy is a good choice. The Auth Proxy is a binary that can be run as a sidecar or background process, and works for any language that connects over a TCP or Unix Domain socket.

All of the connectors follow a secure architecture pattern that uses a proxy tunnel to connect your application to Cloud SQL. The following diagram shows a simplified version of that architecture:

We’re excited to share more details about how the connectors work in a future post, but one of the nice aspects of using the connector is that you don’t need to manage every detail in order for your application to be secure.

But why use a connector at all? 

For people who are already familiar and accustomed to managing all the overhead of connecting securely, it’s perfectly fine to continue in the traditional approach. However, if you’re looking to offload as much work as possible onto Cloud SQL, then a connector will provide all the benefits of connecting securely and then some.

To name a few:

Convenience - Eliminate the need to juggle Authorized Networks or SSL certificates.

Improved security - Use mutually authenticated TLS (v1.3), independent from the database protocol.

Connection authorization - Control who can connect (not just log in!) to your database via IAM roles and permissions.

Automatic IAM database authentication - Choose a passwordless experience and stop worrying if you’ve accidentally pushed your credentials to source control.

IAM conditions with Cloud SQL - Narrow down permissions to specific Cloud SQL instances.

Connector enforcement - Only allow connections using the Cloud SQL connectors

Open standards - The connectors build on the existing standards established by database drivers, so using them is as simple as adding a dependency to your app with a few lines of code.

Open source - All the connectors are open source and actively maintained on GitHub.

Using a connector means letting Google software engineers handle the code connecting your application to the database so you can spend your time building a better product for your users.

In future posts, we will focus on each connector in detail, looking at how to use them, how they work behind the scenes, and additional features not covered here.