Cloud SQL Proxy for secure connections in GCP - Commands & Configuration

Introduction

Connecting to a Cloud SQL database securely can be tricky because you want to keep your data safe and avoid exposing your database to the internet. Cloud SQL Proxy helps by creating a secure tunnel between your local machine or server and the Cloud SQL instance, so you can connect safely without opening up your database to the world.

When you want to connect to a Cloud SQL database from your local computer without exposing the database to the internet.

When your application runs outside Google Cloud but needs secure access to a Cloud SQL instance.

When you want to avoid managing IP whitelists or SSL certificates manually for your database connections.

When you want to simplify authentication by using Google Cloud IAM permissions instead of database user passwords.

When you need a secure and encrypted connection to Cloud SQL from a development environment or a CI/CD pipeline.

Commands

Download the Cloud SQL Proxy binary and make it executable so you can run it on your Linux machine.

Terminal

wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy && chmod +x cloud_sql_proxy

Expected Output

No output (command runs silently)

Start the Cloud SQL Proxy to create a secure tunnel to the Cloud SQL instance named 'my-instance' in the 'us-central1' region of your project. It listens locally on port 5432 for PostgreSQL connections.

Terminal

./cloud_sql_proxy -instances=project:us-central1:my-instance=tcp:5432

Expected Output

2024/06/01 12:00:00 Listening on 127.0.0.1:5432 for project:us-central1:my-instance

2024/06/01 12:00:00 Ready for new connections

→

-instances - Specifies the Cloud SQL instance connection name and local port mapping.

Connect to the Cloud SQL PostgreSQL database through the proxy using the local port 5432. This command uses the local tunnel created by the proxy to securely access the database.

Terminal

psql -h 127.0.0.1 -p 5432 -U myuser -d mydatabase

Expected Output

psql (14.5)

Type "help" for help.



mydatabase=>

→

-h - Host address, here the local proxy address.

→

-p - Port number where the proxy listens.

→

-U - Database user name.

Stop the Cloud SQL Proxy when you no longer need the secure connection.

Terminal

killall cloud_sql_proxy

Expected Output

No output (command runs silently)

Key Concept

If you remember nothing else from this pattern, remember: Cloud SQL Proxy creates a secure, encrypted tunnel so you can connect to your Cloud SQL database safely without exposing it to the internet.

Common Mistakes

Trying to connect directly to the Cloud SQL instance IP without using the proxy or proper IP whitelisting.

The database is not exposed publicly by default, so the connection will fail or be blocked for security reasons.

Use Cloud SQL Proxy to create a secure tunnel or configure authorized networks properly.

Not making the Cloud SQL Proxy binary executable before running it.

The proxy will not start and will show a permission denied error.

Run chmod +x on the downloaded proxy binary to make it executable.

Using the wrong instance connection name format or misspelling it.

The proxy cannot find the Cloud SQL instance and will fail to connect.

Use the exact instance connection name in the format project:region:instance.

Summary

Download and make the Cloud SQL Proxy executable to run it on your machine.

Start the proxy with the correct instance connection name to create a secure tunnel.

Connect to your Cloud SQL database locally through the proxy using standard database clients.

Stop the proxy when finished to close the secure connection.

Practice

1. What is the main purpose of the Cloud SQL Proxy when connecting to a Cloud SQL database?

easy

A. To create a secure tunnel hiding credentials and IP addresses

B. To speed up database queries by caching results

C. To automatically backup the database

D. To convert SQL queries into NoSQL format

Solution

1. Step 1: Understand Cloud SQL Proxy role

   The Cloud SQL Proxy creates a secure connection tunnel to the Cloud SQL database, protecting credentials and IPs.

2. Step 2: Compare options

   Options A, B, and C describe unrelated functions like query conversion, caching, or backup, which are not proxy features.

3. Final Answer:

   To create a secure tunnel hiding credentials and IP addresses -> Option A

4. Quick Check:

   Cloud SQL Proxy = Secure tunnel [OK]

Hint: Proxy hides credentials and IPs for secure connection [OK]

Common Mistakes:

• Thinking proxy speeds up queries
• Confusing proxy with backup service
• Assuming proxy changes query types

2. Which command correctly starts the Cloud SQL Proxy for a Cloud SQL instance named my-instance in project my-project?

easy

A. gcloud sql proxy start --instance=my-instance

B. cloud_sql_proxy --instance=my-instance --project=my-project

C. cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:5432

D. start_sql_proxy --project=my-project --instance=my-instance

Solution

1. Step 1: Recall correct Cloud SQL Proxy syntax

   The correct syntax uses -instances=project:region:instance=tcp:port format to specify the instance and port.

2. Step 2: Evaluate options

   cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:5432 matches the correct syntax. Options A, C, and D use incorrect commands or flags not supported by Cloud SQL Proxy.

3. Final Answer:

   cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:5432 -> Option C

4. Quick Check:

   Correct proxy start command = cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:5432 [OK]

Hint: Use -instances=project:region:instance=tcp:port format [OK]

Common Mistakes:

• Using gcloud instead of cloud_sql_proxy command
• Wrong flag names like --instance instead of -instances
• Omitting region in instance name

3. Given this command to start Cloud SQL Proxy:
cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:3306
What happens when your application connects to localhost:3306?

medium

A. It connects securely to the Cloud SQL instance through the proxy

B. It connects to a local MySQL server running on port 3306

C. It fails because port 3306 is blocked by default

D. It connects directly to Cloud SQL without encryption

Solution

1. Step 1: Understand proxy port forwarding

   The proxy listens on localhost port 3306 and forwards connections securely to the Cloud SQL instance.

2. Step 2: Analyze connection behavior

   Connecting to localhost:3306 goes through the proxy tunnel, not a local database, ensuring secure access.

3. Final Answer:

   It connects securely to the Cloud SQL instance through the proxy -> Option A

4. Quick Check:

   Localhost port = proxy tunnel to Cloud SQL [OK]

Hint: Localhost port forwards securely via proxy to Cloud SQL [OK]

Common Mistakes:

• Assuming connection is to local database
• Thinking port 3306 is blocked by default
• Believing connection skips encryption

4. You started Cloud SQL Proxy with:
cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:5432
Your app tries to connect to localhost:5432 but fails. What is the most likely cause?

medium

A. The proxy command is missing the database user flag

B. Port 5432 is already in use on localhost

C. The Cloud SQL instance is not in the us-central1 region

D. The app must connect to the Cloud SQL IP directly

Solution

1. Step 1: Check port conflict possibility

   If port 5432 is already used by another process, the proxy cannot bind to it, causing connection failure.

2. Step 2: Evaluate other options

   The Cloud SQL instance is not in the us-central1 region is unlikely if instance region is correct; The proxy command is missing the database user flag is incorrect because proxy does not require user flag; The app must connect to the Cloud SQL IP directly ignores proxy usage.

3. Final Answer:

   Port 5432 is already in use on localhost -> Option B

4. Quick Check:

   Port conflict = connection fail [OK]

Hint: Check if localhost port is free before starting proxy [OK]

Common Mistakes:

• Assuming proxy needs database user flag
• Trying to connect directly to Cloud SQL IP
• Ignoring port conflicts on localhost

5. You want to run Cloud SQL Proxy on a Compute Engine VM to allow multiple apps to connect securely to your Cloud SQL instance. Which approach is best to ensure secure and scalable connections?

hard

A. Connect apps directly to Cloud SQL IP with SSL certificates, skipping the proxy

B. Run separate Cloud SQL Proxy instances per app on different ports on the VM

C. Use Cloud SQL Proxy only locally on developer machines, not on VMs

D. Run one Cloud SQL Proxy instance on the VM, listening on a shared port, and configure apps to connect to localhost

Solution

1. Step 1: Understand proxy usage on shared VM

   Running a single proxy instance on the VM listening on one port allows multiple apps to connect securely via localhost, simplifying management.

2. Step 2: Evaluate alternatives

   Run separate Cloud SQL Proxy instances per app on different ports on the VM adds complexity with multiple proxies; Connect apps directly to Cloud SQL IP with SSL certificates, skipping the proxy exposes IP and requires SSL setup; Use Cloud SQL Proxy only locally on developer machines, not on VMs limits proxy use unnecessarily.

3. Final Answer:

   Run one Cloud SQL Proxy instance on the VM, listening on a shared port, and configure apps to connect to localhost -> Option D

4. Quick Check:

   Single proxy instance for multiple apps = best practice [OK]

Hint: One proxy instance per VM, multiple apps connect locally [OK]

Common Mistakes:

• Running multiple proxies causing port conflicts
• Skipping proxy and exposing IPs
• Limiting proxy use to local machines only