Cloud SQL Proxy for secure connections in GCP - Mini Project: Build & Apply

Cloud SQL Proxy for secure connections

📖 Scenario: You are setting up a secure connection to a Google Cloud SQL database from a local machine. To keep your database safe, you will use the Cloud SQL Proxy, which acts like a secure tunnel between your computer and the database.This project will guide you step-by-step to configure and run the Cloud SQL Proxy correctly.

🎯 Goal: Set up and run the Cloud SQL Proxy to securely connect to a Cloud SQL instance using the instance connection name and a service account key.

📋 What You'll Learn

Use the exact Cloud SQL instance connection name my-project:us-central1:my-instance

Use the service account key file named service-account.json

Create a variable for the proxy command with the correct flags

Run the Cloud SQL Proxy with the correct command line

💡 Why This Matters

🌍 Real World

Cloud SQL Proxy is used to securely connect local or external applications to Google Cloud SQL databases without exposing the database to the public internet.

💼 Career

Understanding how to configure and run Cloud SQL Proxy is essential for cloud engineers and developers working with Google Cloud databases to ensure secure and reliable database connections.

1

Set the Cloud SQL instance connection name

Create a variable called INSTANCE_CONNECTION_NAME and set it to the exact string "my-project:us-central1:my-instance".

GCP

# Your code here

Hint

The instance connection name looks like project:region:instance.

2

Set the service account key file path

Create a variable called SERVICE_ACCOUNT_KEY and set it to the exact string "service-account.json".

GCP

INSTANCE_CONNECTION_NAME = "my-project:us-central1:my-instance"
# Your code here

Hint

The service account key file is a JSON file downloaded from Google Cloud Console.

3

Create the Cloud SQL Proxy command string

Create a variable called proxy_command and set it to f"./cloud_sql_proxy -instances={INSTANCE_CONNECTION_NAME}=tcp:5432 --credentials-file={SERVICE_ACCOUNT_KEY}".

GCP

INSTANCE_CONNECTION_NAME = "my-project:us-central1:my-instance"
SERVICE_ACCOUNT_KEY = "service-account.json"
# Your code here

Hint

The proxy command uses the instance connection name and the credential file to open a secure TCP connection on port 5432.

4

Run the Cloud SQL Proxy command

Write the exact line to run the Cloud SQL Proxy using the proxy_command variable with the os.system() function.

GCP

INSTANCE_CONNECTION_NAME = "my-project:us-central1:my-instance"
SERVICE_ACCOUNT_KEY = "service-account.json"
proxy_command = f"./cloud_sql_proxy -instances={INSTANCE_CONNECTION_NAME}=tcp:5432 --credentials-file={SERVICE_ACCOUNT_KEY}"
# Your code here

Hint

Use import os at the top and then run os.system(proxy_command) to start the proxy.

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