Allow signing of URLs from default credentials

[ThatsAMorais]

When an application is run on Google Cloud Platform there are usually a set of default credentials populated in GOOGLE_APPLICATION_CREDENTIALS. However, this is only a token and does not contain a key used for signing uploads; this requires mounting a service account key into the pod and overriding the environment. There may be other ways to achieve this, as well.

For example, if one uses the SDK's generate_signed_url method hosted on GCP and pass 'Client()._credentials' as the credentials, the error response says the credentials provided do not contain a key. If one overrides GOOGLE_APPLICATION_CREDENTIALS with a key.json then the operation is successful.

If the token can be used to access the meta-data store, could a method be written in the SDK to accept a default credentials token? The benefit is not having to mount a file and override the environment. Am I misunderstanding the relationship between the credentials/token of a pod or instance, and a service account key?

Related: #50 (comment)

[jezhumble]

Try this: https://gist.github.com/jezhumble/91051485db4462add82045ef9ac2a0ec

[danihodovic]

Any update on this in 2022?

[salrashid123]

generating a signedurl requires direct or indirect access to a private key.

the direct access is if you have the private key onhand. indirect access is through iam .signBlob() API call.

for the latter to work, the source credential nees the iam TokenCreator permissions on svc account that will issue the signing

most auth libraries now support signedurl through impersonation if it detects impersonation is in use (i.,e implicitly tries to use that api above.)

if it helps, here's a small article about generating the urls from gce, clodu run, etc

[pataquets]

@ThatsAMorais You can run GCloud SDK outside of GCP using Application Default Credentials (as you do with your user account) and make it work as a Service Account by "impersonating the SA".
Notice, though, that for this to work you need to have the "Service Account Token Creator" permission role, which will allow you to create tokens (as @salrashid123 already pointed out) "impersonating" another account (the Service Account).

When you have the permission, run the gcloud auth ADC login procedure, but "upgrading" you ADC credentials to an impersonated SA, like this:

$ gcloud auth application-default login --impersonate-service-account=[your-service-account-id]@developer.gserviceaccount.com

After that, your local ADC credentials are tied to the said SA. Keep in mind that audit trails for operations performed with this SA keep record of who requested the impersonation (ie. you).
You can check it by comparing your current ADC credentials file with the newly generated above.

This way, your code will run outside GCP exactly the same than on GCP, without any conditional code and without having to juggle with JSON credentials, which is highly discouraged by Google.

EDIT: If you've found this answer hard to find and want to make it more visible, I've also cross-posted it as an answer to an unresolved Stack Overflow question, which you're welcome to upvote here.