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

4
votes

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?

1
google-cloud-platformgoogle-cloud-sqlcloud-sql-proxy
Your analysis is good. Private IP versus Proxy provides no clear winner as both are good and secure solutions. This comes down to a design/architecture decision. My preference is Cloud SQL Proxy. My containers should not worry about how to address and connect to the database. Now look forward, your company decides to share that database across regions. Now all of your containers have to be rebuilt as they store hard details and non-migratable configurations about Cloud SQL. One assumption that you are making: adding another layer or hop makes almost zero difference in database performance. - John Hanley
@JohnHanley do you think there is a difference between managing the IAM material vs the SSL material? What if the DNS record was pointed to a hostname rather than a hard coded IP? Does that make the non-migratable configuration easier? - Erik L
There is no "material" with IAM unless you mean service account JSON key. With SSL there is "material" - the certificate files plus the issue of rotating certificates. You can use DNS, but I would not recommend a public DNS server. Cloud SQL Proxy is a very good solution - to use anything else requires justification IMHO. - John Hanley

1 Answers

6
votes

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.