... or into new env variable.
Usecase is using service in bitbucket pipelines:

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).
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 notifications@github.com
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
https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/323?email_source=notifications&email_token=AAELF362XOYSZABY6PS6JIDQQ4IKPA5CNFSM4JF4WJX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNRGPQ#issuecomment-547033918,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAELF34JR4Q4MYXB4WDJSITQQ4IKPANCNFSM4JF4WJXQ
.
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_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.
Most helpful comment
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 notifications@github.com
wrote: