<p>Does anyone know the pros and cons for installing the CloudSQL-Proxy (that allows us to connect securely to CloudSQL) on a Kubernetes cluster as a service as opposed to making it a sidecar against the application container?</p>
<p>I know that it is mostly used as a sidecar. I have used it as both (in non-production environments), but I never understood why sidecar is more preferable to service. Can someone enlighten me please?</p>

Sayon Roy Choudhury
<p>The sidecar pattern is preferred because it is the easiest and more secure option. Traffic to the Cloud SQL Auth proxy is not encrypted or authenticated, and relies on the user to restrict access to the proxy (typically be running local host).</p>
<p>When you run the Cloud SQL proxy, you are essentially saying &quot;I am user X and I'm authorized to connect to the database&quot;. When you run it as a service, anyone that connects to that database is connecting authorized as &quot;user X&quot;.</p>
<p>You can see this <a href="https://github.com/GoogleCloudPlatform/cloudsql-proxy/tree/main/examples/k8s-service#a-word-of-warning" rel="noreferrer">warning in the Cloud SQL proxy example running as a service in k8s</a>, or watch this video on <a href="https://www.youtube.com/watch?v=CNnzbNQgyzo" rel="noreferrer">Connecting to Cloud SQL from Kubernetes</a> which explains the reason as well.</p>
