Repository navigation
Allow raw JSON to be passed into GOOGLE_APPLICATION_CREDENTIALS env variable #323
Description
Activity
While this isn't the exact useless you described, you can use the
-tokenflag to pass in credentials to the proxy when it starts (which could rely on a env var).- 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.
- 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> .Reacted by Myroslav Holyak and Thorben
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...
+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.
+1 for this. Requiring that the file be present on the filesystem makes
cloud_sql_proxydifficult to use withterraform. This code search of GitHub shows that the only way anybody has figured out how to deploycloud_sql_proxywithterraformis to use k8s volume mounts.I think the scarcity of
terraform+cloud_sql_proxyusage on GitHub points to a serious usability problem. It is, of course, up to you whether you want to supportterraform. If you do, allowing us to set the entire service account key as an env var would makecloud_sql_proxymuch easier to use. Thanks for keeping this issue open and considering this feature.Reacted by Thorben and Andrew SlatteryWe 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.
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.
- added 2 commits that reference this issue
on Sep 19, 2022 - added a commit that references this issue
on Sep 23, 2022 This is on main now and will be available in the next preview release of v2 (preview 2).
Reacted by Ryan Boehning
... or into new env variable.
Usecase is using service in bitbucket pipelines: