Using Cloud SQL Auth Proxy with Kubernetes Workloads
The Cloud SQL Auth Proxy is the recommended way to connect applications running in Kubernetes to Cloud SQL securely. It handles:
IAM-based authentication
Automatic encryption (TLS)
Secure connections without IP whitelisting
Automatic certificate rotation
Instead of exposing Cloud SQL publicly or managing SSL manually, you run the proxy as a sidecar container or as a separate Deployment/Service.
1. Ways to Use the Cloud SQL Auth Proxy in Kubernetes
There are two common deployment patterns:
Option A — Sidecar container (recommended)
The proxy runs inside the same Pod as your application.
✔ Simplest
✔ Ensures 1:1 connection
✔ Secure and isolated
✔ Preferred for most workloads
Option B — Standalone Deployment + ClusterIP Service
A shared proxy service that multiple workloads connect through.
✔ Reduces sidecar overhead
✔ Good for many small Pods
✘ Less isolated
✘ Not ideal for high-security environments
2. Requirements
Before deploying:
A Cloud SQL instance (MySQL/Postgres/SQL Server).
A Kubernetes cluster (e.g., GKE Standard or Autopilot).
A service account with the role:
roles/cloudsql.client
A Kubernetes secret containing the service account key (if not using Workload Identity).
3. Example: Running Cloud SQL Proxy as a Sidecar
Below is a minimal Deployment manifest for proxy-as-sidecar.
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-with-sql
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
serviceAccountName: myapp-sa
containers:
- name: app
image: gcr.io/my-project/my-app:latest
env:
- name: DATABASE_HOST
value: "127.0.0.1"
- name: DATABASE_PORT
value: "5432"
ports:
- containerPort: 8080
- name: cloud-sql-auth-proxy
image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.9.0
args:
- "--instance=my-project:us-central1:my-db-instance"
- "--port=5432"
securityContext:
runAsNonRoot: true
Connecting from the application
Since the proxy listens on localhost, the app connects to:
host: 127.0.0.1
port: 5432
user: <db user>
password: <db password>
dbname: <db name>
No public IP, SSL cert, or VPC configuration is required.
4. Using Workload Identity (recommended)
Workload Identity lets Pods authenticate to Google Cloud without service account keys.
Steps:
Enable Workload Identity on your GKE cluster.
Create a Google Cloud service account:
gcloud iam service-accounts create sql-proxy-sa
Give it Cloud SQL permissions:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:sql-proxy-sa@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/cloudsql.client"
Map K8s service account to the Google service account:
gcloud iam service-accounts add-iam-policy-binding \
sql-proxy-sa@PROJECT_ID.iam.gserviceaccount.com \
--member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL/providers/PROVIDER/subject/system:serviceaccount:NAMESPACE:myapp-sa" \
--role="roles/iam.workloadIdentityUser"
Your Pods can now run the proxy without storing any keys.
5. Using the Proxy as a Standalone Deployment
deployment-proxy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: cloud-sql-proxy
spec:
replicas: 2
selector:
matchLabels:
app: cloud-sql-proxy
template:
metadata:
labels:
app: cloud-sql-proxy
spec:
serviceAccountName: sql-proxy-sa
containers:
- name: cloud-sql-proxy
image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.9.0
args:
- "--instance=my-project:us-central1:my-db-instance"
- "--port=5432"
Expose via internal service:
apiVersion: v1
kind: Service
metadata:
name: cloud-sql-proxy-service
spec:
selector:
app: cloud-sql-proxy
ports:
- port: 5432
targetPort: 5432
protocol: TCP
type: ClusterIP
Your app connects to:
cloud-sql-proxy-service:5432
6. Best Practices
✔ Prefer sidecar proxies for security
Prevents cross-Pod interference and limits blast radius.
✔ Use Workload Identity instead of service account JSON keys
More secure and avoids secret rotation issues.
✔ Keep the proxy version up to date
Google regularly updates the Cloud SQL connector and proxy images.
✔ Monitor connection limits
Cloud SQL has a max concurrent connection count—scale wisely.
✔ Use connection pooling (pgBouncer / Cloud SQL Insights)
Especially for serverless or autoscaling workloads.
7. Summary
Using the Cloud SQL Proxy with Kubernetes:
Provides secure, authenticated, encrypted connections
Eliminates egress IP whitelisting or SSL certificate management
Works seamlessly as a sidecar or shared proxy service
Integrates neatly with Workload Identity for keyless security
This is the recommended and safest way to connect Kubernetes applications to Cloud SQL.
Learn GCP Training in Hyderabad
Read More
High-Availability Patterns in Cloud SQL for Enterprise Apps
Implementing Composite Indexing in Firestore
Performing OLAP Queries with BigQuery on Cloud SQL Federated Tables
Using Bigtable with Grafana for Real-Time Monitoring Dashboards
Visit Our Quality Thought Training Institute in Hyderabad
Subscribe by Email
Follow Updates Articles from This Blog via Email
No Comments