-
Notifications
You must be signed in to change notification settings - Fork 349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow raw JSON to be passed into GOOGLE_APPLICATION_CREDENTIALS env variable #323
Comments
While this isn't the exact useless you described, you can use the |
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>
.
|
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 I think the scarcity of |
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. |
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. |
Thanks @ryboe. That makes perfect sense. This is such an easy and quick change, I'll pull it into my queue. |
This is on main now and will be available in the next preview release of v2 (preview 2). |
... or into new env variable.
Usecase is using service in bitbucket pipelines:
The text was updated successfully, but these errors were encountered: