WAI
Status Update
No update yet.
Comments
ch...@google.com
It is possible to set a property to credential file via
gcloud config set auth/credential_file_override CREDENTIAL_FILE
this property is not documented and subject to change at any new release.
Instead you can use environment variable CLOUDSDK_CONFIG=path to control where credentials are used and can be shared among different users.
After setting this environment variable you should
gcloud auth activate-service-account --key-file...
Every gcloud command has --account, --project and --configuration options which allow you to control which credentials and properties are used per command invocation.
gcloud config set auth/credential_file_override CREDENTIAL_FILE
this property is not documented and subject to change at any new release.
Instead you can use environment variable CLOUDSDK_CONFIG=path to control where credentials are used and can be shared among different users.
After setting this environment variable you should
gcloud auth activate-service-account --key-file...
Every gcloud command has --account, --project and --configuration options which allow you to control which credentials and properties are used per command invocation.
vi...@google.com
Marking as WAI, please reopen if that is wrong.
yo...@liftigniter.com.appstempdomain.goog
I know that it is possible to use a service account using either gcloud auth activate-service-account --key-file <json file>. But it modifies the home directory, which may be inappropriate for cron jobs and other server tasks. And it is needlessly non-uniform compared to all the SDKs.
ma...@hapara.com
I am configuring a server on which I run both gcloud commands and apps using application default credentials as strongly recommended by your docs. I use multiple service accounts.
I can run the apps by installing a key file and then setting GOOGLE_APPLICATION_CREDENTIALS before running the app.
I can run gcloud using the --account flag, but to install an account I must activate the account _and_ fuss about the side-effect of changing the default account and whether that might be used by other apps.
I can see how it might be a breaking change to have gcloud respect the GOOGLE_APPLICATION_CREDENTIALS variable, but if it took a --key-file flag for any operation in place of an --account flag then that would simplify server configuration.
I can run the apps by installing a key file and then setting GOOGLE_APPLICATION_CREDENTIALS before running the app.
I can run gcloud using the --account flag, but to install an account I must activate the account _and_ fuss about the side-effect of changing the default account and whether that might be used by other apps.
I can see how it might be a breaking change to have gcloud respect the GOOGLE_APPLICATION_CREDENTIALS variable, but if it took a --key-file flag for any operation in place of an --account flag then that would simplify server configuration.
be...@gmail.com
It would be very helpful to have a uniform way to inject credentials into programs that use the GCP APIs.
The system I am working on is composed of several small scripts. Some of the simple ones are written in Bash (which use gcloud to access GCP); the more complex ones are written in Python (using the official Python libraries). Because of the behaviour reported in this issue, as a consumer of the scripts I have to know which language they are written in so that I can correctly inject credentials (or eagerly provide credentials in all possible ways). And my use of the system is not robust against a script being rewritten from Bash into Python (which often happens as they become more complex over time).
Enhancing gcloud to respect GOOGLE_APPLICATION_CREDENTIALS would be very helpful to simplify this situation.
The system I am working on is composed of several small scripts. Some of the simple ones are written in Bash (which use gcloud to access GCP); the more complex ones are written in Python (using the official Python libraries). Because of the behaviour reported in this issue, as a consumer of the scripts I have to know which language they are written in so that I can correctly inject credentials (or eagerly provide credentials in all possible ways). And my use of the system is not robust against a script being rewritten from Bash into Python (which often happens as they become more complex over time).
Enhancing gcloud to respect GOOGLE_APPLICATION_CREDENTIALS would be very helpful to simplify this situation.
ch...@gmail.com
Strong agreement with #5 ma...@hapara.com. This functionality is very useful for security best practices and a --key-file global flag would be an acceptable substitute if that was somehow easier to implement.
CLOUDSDK_CONFIG is a substandard substitute because it requires writing credentials somewhere else on the filesystem. If you already have your secret key securely loaded in an env var, or mountpoint, this adds unnecessary distribution of your credentials and you may have to remember to wipe them when you're done, every time.
CLOUDSDK_CONFIG is a substandard substitute because it requires writing credentials somewhere else on the filesystem. If you already have your secret key securely loaded in an env var, or mountpoint, this adds unnecessary distribution of your credentials and you may have to remember to wipe them when you're done, every time.
Description
It would be helpful to test that GOOGLE_APPLICATION_CREDENTIALS is correctly set to a service account. Currently, to test GOOGLE_APPLICATION_CREDENTIALS you have to write a script in one of the other SDKs (e.g. python, java, go). You can’t easily verify from the shell that GOOGLE_APPLICATION_CREDENTIALS is correct.
On a non-GCE instance, one often wants to use a Service Account to access GCP resources using a shell script (e.g. cron job that periodically polls some API). Scripts are often run under different users (e.g. root), and it is cumbersome to have to set up ~/.config/gcloud for each user.
I initially asked this in stackoverflow, but user Kamran requested that I create an issue: