0

We have a Java app which uses Google Auth to allow uses in. The app needs to connect to a Google Cloud SQL database which is locked down behind IP restrictions.

We need to use Cloud SQL Socket Factory with Cloud SQL Proxy to get access to the database, this requires Application Default Credentials with an environment variable GOOGLE_APPLICATION_CREDENTIALS pointing at service account credentials JSON file. I'm unsure of how to store this securely, putting that file on the user's PC is obviously not secure.

As per best practices on https://cloud.google.com/docs/authentication/production, it says

You can use an environment variable pointing to credentials outside of the application's source code, such as Cloud Key Management Service.

But this doesn't go on to explain how to do it. How can I store this file securely, in KMS or otherwise, in a way that only authorized Google accounts can access?

Timm
  • 12,553
  • 4
  • 31
  • 43

2 Answers2

1

First, the Cloud SQL proxy and the Cloud SQL JDBC socket factory are two different implementations of the same thing. The Socket Factory is used from inside your application, while the proxy is an external process. There is no reason to use both at the same time.

Second, how to secure your app depends a lot on how you plan to distribute and run it. If it's a web app, you'll likely create a "service account" that represents the privileges you want your application to have, and then restrict access to the front end of the application using whatever works (firewall, oauth, etc).

If your app is something locally distributed to a users platform, then it's a bit more complicated and much harder to secure. The problem is, anyone with access to your app could potentially access your database or other resources. Since you can't use gcloud, you could either re-implement your own auth layer (like gcloud auth application-default login) that has the user login and generated a temporary credential file that can be used to connect.

Alternatively, you include the credentials with the application itself. You could embed them directly, but if it gets compromised then you have to redistribute the application. What would be potentially safer would be to distribute the credential file(s) separate, and create different ones for each user. This way if one is compromised, you only need to rotate the compromised account.

To my knowledge, there is no way to use KMS to store a service account, as you would still need some way to authenticate with KMS itself.

kurtisvg
  • 3,412
  • 1
  • 8
  • 24
0

You are right: using service account key file isn't a good practice and it's a security breach (in addition of storing it securely on computer, you have to rotate it every 90 days, you can copy the file, send it by email and even commit it publicly on git repo!!)

However, for using cloud SQL proxy, you can simply use your own credential. perform a gcloud auth application-default login. By sure that your user is authorized on the database and that's all!

Note: be sure to not use the param -credential when you start your cloud sql proxy

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • Just to confirm - this requires users of our app to install Google Cloud SDK and run that command? There's no way to seamlessly connect from only our application code? – Timm May 29 '20 at 14:30
  • Yes, the user need to install it, but it's more for developer than user. If you need to deploy standalone app on user computer, you can hardcode the service account into your code. In any case, limit strictly the role of the service account. If you send outside the service, even embedded in your code, you aren't sure that it won't be recovered by intruders. – guillaume blaquiere May 29 '20 at 15:24
  • We're unable to get users to install the SDK due to locked down devices. If we were to hardcode them into the application, do you know much about the "Cloud SQL Socket Factory" which seems to be the only way to use Java and Cloud Proxy, and how we'd apply those credentials? It looks like it uses "Application Default Credentials", so supplying credentials manually doesn't appear possible. – Timm May 29 '20 at 15:45
  • I only deployed application on server, never on end user computer. I think there is something possible to package in your final binary. I'm not sure, and it's depend on the OS of the user. not an easy thing. – guillaume blaquiere May 29 '20 at 20:00