Two Tunnels to a Remote DB: Cloud SQL Auth Proxy vs kubectl port-forward
Two ways to reach a remote DB on a local port: the Cloud SQL Auth Proxy (Admin API + IAM) and kubectl port-forward (kubeconfig). Same localhost outcome, different auth paths.
Same outcome, a local port → remote DB, via two different auth paths:
| Cloud SQL Auth Proxy | kubectl port-forward | |
|---|---|---|
| For | managed Cloud SQL instances | any DB running in a k8s pod/svc |
| Addressed by | project:region:instance | namespace + svc/pod |
| Auth path | Cloud SQL Admin API + IAM (ADC / service account) | your kubeconfig (GKE creds) |
| Encryption | ephemeral TLS tunnel to the instance | tunnel via the k8s API server |
| Client sees | plain localhost TCP (native wire protocol) | same |
The client always speaks the normal DB protocol to 127.0.0.1:PORT; the tunnel is transparent, the client doesn’t know there’s a layer in between.
From this session: Postgres / MySQL reached via cloud_sql_proxy (Admin API); ClickHouse lives in GKE, so it’s reached via a containerized kubectl port-forward, which is why only it needs a one-time gcloud container clusters get-credentials.
Two tunnels, different auth paths, but the client always sees the native DB protocol on
127.0.0.1:PORT.
References
- Cloud SQL Auth Proxy: https://cloud.google.com/sql/docs/postgres/sql-proxy
- Cloud SQL Auth Proxy demystified: https://engineering.sada.com/cloud-sql-auth-proxy-demystified-54dd803d1474
- cloud-sql-proxy (GitHub): https://github.com/GoogleCloudPlatform/cloud-sql-proxy
Related: back to the remote DB overview; this tunnel lands you on the five coordinates at 127.0.0.1:PORT.