Secure, IAM‑Based Cloud SQL Connections with the Auth Proxy on Compute Engine

Problem: Manual SSL and Network Management for Cloud SQL

When a Cloud SQL instance is exposed over the public internet you normally need a client certificate, a list of authorized networks, and a static IP for your Compute Engine VM. In dynamic environments where VMs are frequently created, destroyed, or moved across regions, keeping certificates up‑to‑date and IP whitelists accurate becomes a maintenance nightmare. It also introduces a risk surface: a compromised VM could leak its certificate or IP, giving attackers a foothold.

Thesis: Use the Cloud SQL Auth Proxy to let IAM do the heavy lifting

The Auth Proxy is a small, open‑source binary that runs on the client host and forwards traffic to Cloud SQL over a private IP. It authenticates using a short‑lived OAuth token that the VM’s service account can request. The token is verified by Cloud SQL, which then allows the connection without any SSL certificates or IP whitelisting. This keeps the principle of least privilege intact and removes the operational burden of certificate management.

How the Proxy Works

Architecture diagram (labels only, no drawn image):

• Compute Engine VM (service account)
• Auth Proxy (listens on localhost)
• Cloud SQL instance (private IP)
• IAM token exchange

Concrete Example: PostgreSQL on Compute Engine

1. Create the Cloud SQL instance (public IP disabled, private IP enabled). Grant the instance the cloudsql.instances.connect permission to the project’s default compute service account or a dedicated one.

   # gcloud sql instances create my-postgres \
     --database-version=POSTGRES_15 \
     --region=us-central1 \
     --tier=db-f1-micro \
     --no-assign-public-ip
   

2. Provision a Compute Engine VM in the same VPC and attach a service account with the roles/cloudsql.client role.

   # gcloud compute instances create sql-client-vm \
     --zone=us-central1-a \
     --machine-type=e2-micro \
     --image-family=debian-12 \
     --image-project=debian-cloud \
     --service-account=[contact removed] \
     --scopes=https://www.googleapis.com/auth/cloud-platform
   

3. Install the Auth Proxy binary on the VM. The latest release can be fetched from the official GitHub releases page.

   curl -L https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -o cloud_sql_proxy
   chmod +x cloud_sql_proxy
   sudo mv cloud_sql_proxy /usr/local/bin/
   

4. Start the proxy pointing to the instance and listening on the local PostgreSQL port.

   cloud_sql_proxy \
     -instances=$PROJECT_ID:us-central1:my-postgres=tcp:5432 \
     -credential_file=/home/ubuntu/.config/gcloud/application_default_credentials.json \
     -log_debug_stdout
   

   Run this as a background service (e.g., systemd unit) so it stays alive after reboots.

5. Connect with a standard client as if the database were local.

   psql -h localhost -U postgres -d postgres
   

   No certificate or password is required; the proxy handles authentication.

Verification Checklist

• Verify that psql connects without SSL errors.
• Check Cloud Logging for a “proxy connection” entry; it should show the client IP as the VM’s internal IP.
• Confirm that no traffic appears on the instance’s public IP (or that the public IP is disabled).
• Run gcloud sql instances describe my-postgres --format=json and ensure settings.ipConfiguration.privateNetwork references the correct VPC.

Trade‑offs and Limitations

• The proxy adds a small network hop (VM → proxy → Cloud SQL). For latency‑sensitive workloads the extra round‑trip may be noticeable, though typically <10 ms.
• Keep the proxy binary up‑to‑date; older releases may lack support for newer IAM token formats or database engine changes.
• The Auth Proxy does not replace VPC Service Controls. If you need to enforce network‑level data exfiltration controls, combine the proxy with private IP and VPC peering.
• Service accounts must be tightly scoped: only grant roles/cloudsql.client to the minimal set of VMs.

Actionable Takeaway

Replace manual SSL and IP whitelisting with the Cloud SQL Auth Proxy whenever you run Cloud SQL from Compute Engine, GKE, or on‑premises hosts. It reduces operational overhead, tightens security, and keeps your infrastructure declarative. Start by creating a dedicated service account, granting cloudsql.client, installing the proxy, and testing a local connection. Once verified, automate the proxy startup with systemd or a startup script, and monitor Cloud Logging for any unexpected connection patterns.