Connecting Cloud Run to Cloud SQL Securely with the Auth Proxy and IAM Authentication

Introduction

When a Cloud Run service needs to talk to a Cloud SQL database, managing passwords or IP allowlists adds operational overhead. The Cloud SQL Auth proxy together with IAM database authentication lets you rely on short‑lived OAuth tokens instead of static credentials.

Architecture

Cloud Run runs your application container alongside a sidecar container that contains the Cloud SQL Auth proxy. The proxy opens a local TCP socket (e.g., localhost:5432) and handles the OAuth token exchange with Cloud SQL on behalf of the application. Your app connects to localhost:5432 using a standard driver; the proxy adds the IAM token to each new connection.

Deployment Example

Below is a minimal Cloud Run service definition that adds the Auth proxy as a sidecar. Replace the placeholders with your own values.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: 'SERVICE_NAME'
  namespace: 'PROJECT_ID'
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: 1
    spec:
      containers:
        - name: app
          image: 'REGION-docker.pkg.dev/PROJECT_ID/REPO/IMAGE:TAG'
          env:
            - name: DB_HOST
              value: localhost
            - name: DB_PORT
              value: 5432
            - name: DB_NAME
              value: 'DATABASE_NAME'
        - name: cloudsql-proxy
          image: gcr.io/cloudsql-docker/gce-proxy:1.33.0
          command: ["/cloud_sql_proxy", "-instances=INSTANCE_CONNECTION_NAME=tcp:0.0.0.0:5432", "-credential_file=/secrets/cloudsql/credentials.json"]
          volumeMounts:
            - name: cloudsql-instance-credentials
              mountPath: /secrets/cloudsql
              readOnly: true
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-credentials

Create the secret that holds the service account key with the roles/cloudsql.client role:

gcloud iam service-accounts keys create key.json \
  --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com
kubectl create secret generic cloudsql-credentials \
  --from-file=key.json=key.json

Deploy the service (run from a machine with the Cloud SDK):

gcloud run services replace service.yaml \
  --platform=managed \
  --region=REGION \
  --allow-unauthenticated

Verification & Testing

1. Invoke an endpoint that runs a simple query, for example SELECT version();.
2. Check the response; it should contain the database version string.
3. Look at Cloud Logging for entries from the cloudsql-proxy container. You should see lines like New connection for INSTANCE_CONNECTION_NAME and Successfully refreshed token.
4. To confirm the dependency, temporarily remove the roles/cloudsql.client role from the service account or delete the sidecar container and redeploy. The same request should now fail with a connection error.

Trade‑offs and Limitations

• Latency: each new connection incurs a token‑fetch call, adding a few milliseconds of overhead. Connection pooling in your app can mitigate this.
• Memory: the proxy sidecar runs alongside your app; high concurrency settings increase the number of proxy processes proportionally, raising memory usage.
• Cold starts: the sidecar starts with the application container, so the initial request may see slightly higher latency.
• Version pinning: specify a fixed proxy image tag (as shown) to avoid unexpected updates that could break compatibility.

Closing

Using the Cloud SQL Auth proxy as a sidecar gives you IAM‑based, password‑less access to Cloud SQL from Cloud Run while keeping the deployment model familiar. Verify the setup with a simple query and logging checks, then weigh the latency and memory trade‑offs against the operational simplicity of removing static credentials.