Allow raw JSON to be passed into GOOGLE_APPLICATION_CREDENTIALS env variable

[mholyak]

... or into new env variable.

Usecase is using service in bitbucket pipelines:

[kurtisvg]

While this isn't the exact useless you described, you can use the -token flag to pass in credentials to the proxy when it starts (which could rely on a env var).

[Carrotman42]

Is there a way to store a file to disk using the bitbucket configuration? That's seems like a pretty basic feature it should support (never used it, haven't checked, just a guess). If you can manage that, then the Proxy doesn't need anything extra from what already exists: store that file to disk somewhere, and then point to it using the existing flags/env variables for authentication.

[Carrotman42]

I don't think -token works for this: the json credentials include a private key for obtaining oauth tokens (via Google auth APIs), but -token should take the oauth token itself (implying something else has to call the Google APIs).

…

On Mon, Oct 28, 2019, 10:36 AM Kurtis Van Gent ***@***.***> wrote: While this isn't the exact useless you described, you can use the -token flag to pass in credentials to the proxy when it starts (which could rely on a env var). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#323>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELF34JR4Q4MYXB4WDJSITQQ4IKPANCNFSM4JF4WJXQ> .

[mholyak]

Is there a way to store a file to disk using the bitbucket configuration?

Sure, and I'm using it now to run cloud-proxy in background:

But, if I want to have it as stand-alone service (similar to docker-compose items) I need to define it in special separate section and only env variables are available there...

[gregmsanderson]

+1 for this, seems like a great idea to be able to pass the json content. Since many faas/paas seem to support using secrets in key => value form. So then the content of the json could be stored once, as a secret, and then that file then never needs to be kept in a file system.

[ryboe]

+1 for this. Requiring that the file be present on the filesystem makes cloud_sql_proxy difficult to use with terraform. This code search of GitHub shows that the only way anybody has figured out how to deploy cloud_sql_proxy with terraform is to use k8s volume mounts.

I think the scarcity of terraform+cloud_sql_proxy usage on GitHub points to a serious usability problem. It is, of course, up to you whether you want to support terraform. If you do, allowing us to set the entire service account key as an env var would make cloud_sql_proxy much easier to use. Thanks for keeping this issue open and considering this feature.

[enocom]

We don’t control GOOGLE_APPLICATION_CREDENTIALS and so can’t change how it works. However, there is a CredentialsFromJSON method that we could in theory expose as a CLI flag. That said I don’t understand the use case here and why using a credential file isn’t a reasonable option.

[ryboe]

The use case is: it's easier to pass the credentials into a container as an env var instead of mounting them as a volume. Look at all the templating hoops I had to jump through to deploy Cloud SQL Proxy with Terraform. Also, lots of container environments are restricted (e.g. CI/CD) and don't let you mount volumes. But just about every container environment lets you set env vars.

[enocom]

Thanks @ryboe. That makes perfect sense. This is such an easy and quick change, I'll pull it into my queue.

[enocom]

This is on main now and will be available in the next preview release of v2 (preview 2).