When using a Google Cloud SQL database, is there a difference between a private IP + SSL, or the cloud proxy sidecar?

Question

When trying to evaluate how to connect to a Cloud SQL database from a Google Kubernetes Engine pod, there are a couple of ways to do this. One is to use a sidecar cloud proxy agent. Another is using a private IP and using a SSL connection between the two. Is there a clear case for either? Or do they both serve the same functionality? Is there one that is considered "best practice"?

Cloud SQL Proxy sidecar

The cloud sql proxy sidecar establishes a TCP connection into a proxy service that is hosted on Google's infrastructure. This then connects you to your cloud SQL instance on the Google network.

Pros

• Establishes a secure connection without you having to manage the crypto material in your application
• Connects to the instance and you don't have to manage DNS records or IP addresses

Cons

• You have to create a secret that stores a service account key.
• You have to manage a sidecar instance along side your pod, which if that fails, you no longer can connect to your database
• Latency added due to the number of layers you have to the proxy layers

Private IP + SSL

Using a private IP and connecting the instance to your VPC allows you to use an internal IP address, that is not publicly routed, and keeps traffic in your VPC instance. On top of that, setting up SSL only connections to your database to make sure traffic is secure from point to point.

Pros

• Low latency connection to the database because its a point to point connection
• You manage the keys between the services
• No outside dependencies or systems needed to connect between the two

Cons

• You have to manage the SSL certificate inside of the connection
• You have to verify that the IP and DNS records setup in your cluster are correct

Am I missing something? Do these two indeed provide the same thing? Is there not an absolutely clear winner between the two and you can pick whichever one you see that best fits your style?

Answer 1

Best practice is to use the Proxy. From a secure standpoint they're both good options, but I've found the mess of managing my own SSL keys just a nuisance I didn't need. Also as John mentioned in his comment, if you shift regions, or change IPs for any reason, you have to change the container content rather than just a flag on the proxy startup. You can mitigate that of course using environment variables on the containers, but it's one more thing.

There's a SLIGHT security edge on the proxy IMO as IF your keys get compromised, the window that the ephemeral key generated by the proxy connection is shorter lived than an SSL key generated by yourself (unless you're using the ephermal key calls in the API). So if a vulnerability is found in your app, and a key gets compromised, there's a smaller window that anyone can do malicious things to your DB. But particularly if you're solely on a VPC that's LESS of a concern, but is still greater than zero.