Open doktorjw opened 2 years ago
Hi, thanks for the detailed report.
So does ADC actually return something - but it's not the identity you want? For example, if you are running on a GCE_VM then it will pick up the SA from the VM as part of trying to find ADC.
Are the successful creds the ones obtained by gcloud?
There have been other requests to control more specifically which creds the plugin uses, e.g. to force ADC, or to force gcloud auth. Would that work?
What I've done, is I downloaded the key json file for the service account.
After that, I re-ran the GCloud command that prints the maven configuration for Artifact Registry, but used --json-file
parameter.
You just need to copy the maven settings part this command returns and from there and you're all set.
We are using gitlab, and in our .gitlab-ci.yaml file, we are attempting to publish an artifact like this:
This fails, however, as it cannot obtain the proper credentials (it tries to use the application default credentials (ADC) and it fails because the ADC is only authorized to impersonate the account that it needs). ADC is not authorized to publish to our repository; our company is requiring access to services only through service accounts.
Looking at the common auth code, however, we can get this to work by providing a value for GOOGLE_APPLICATION_CREDENTIALS that points to a file that does not exist.
This makes it fail in the first of the 3 try-catch blocks searching for credentials, and the second block succeeds in what we want --- obtaining the credentials for the impersonated account.
We'd like to be able to do this without this "hack", however -- any chance of a minor enhancement to either allow us to configure which auth mechanism should be used, or to silently see that we are impersonating an account and succeed without providing the GOOGLE_APPLICATION_CREDENTIALS?