Skip to content
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

Support setting a service account key as an env var #374

Closed
ryboe opened this issue Apr 11, 2020 · 2 comments
Closed

Support setting a service account key as an env var #374

ryboe opened this issue Apr 11, 2020 · 2 comments
Assignees

Comments

@ryboe
Copy link

ryboe commented Apr 11, 2020

Currently, if you want to run the proxy with a service account, you pass the -credential_file=/path/to/key.json flag. Deploying this file is a headache, especially if you're using VMs with ephemeral storage or running the proxy in a container.

Since I'm using the containerized cloud_sql_proxy, I think my only option for deploying the key file is to make a custom image with the file copied into the container. This is not ideal for two reasons:

  1. Since the image has a secret baked into it, the image itself becomes a secret that needs to be protected.
  2. I have to set up a private docker registry, like GCR.

It would be nice to have the option of putting the whole JSON string in an env var. Then I could pass the key to the container like this:

docker run -e GOOGLE_CREDENTIALS="${ENTIRE_SERVICE_ACCOUNT_KEY}" gcr.io/cloudsql-docker/gce-proxy

P.S. Thanks for all your work on this project! 🙇

UPDATE: Looking at the usage of cloud_sql_proxy with terraform on GitHub, nearly everyone is using k8s volumes to mount the key file into the container. That's great for them, but I'm not using k8s. I'm just trying to run the proxy on a simple VM.

@dmahugh
Copy link
Contributor

dmahugh commented Apr 13, 2020

Thanks for the feedback, @y0ssar1an, that's an interesting suggestion. That would mean the command itself needs to be secured, but I agree there are scenarios where that could be a useful alternative rather than needing to secure an image that contains the credential file. Closing this for now (since it's not an open bug per se), but I'll add that to the backlog for future consideration.

@dmahugh dmahugh closed this as completed Apr 13, 2020
@kurtisvg
Copy link
Contributor

(This is a duplicate of #323, which we are leaving open)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants