Application Default Credentials and Workload Identity Federation can't sign URLs

[thclark]

Bug report

What is the current behavior?

If using ADCs or WIF, it's not possible to sign URLs because there's no local private key, only a token. So, whether on Cloud Run, Locally, or in a GitHub runner, you have to have the full Service Account JSON key in order to generate signed blobs for storage.

I came across this first in testing a django app, using WIF for authenticating github actions instead of injecting a service account into the runner. But, it will apply anywhere that a django server using django-gcp (or django-storages) is using WIF for authentication.

I believe the same problem will appear when impersonating a service account, since inspecting the credentials generated for that, there doesn't seem to be a key either.

What is the expected behavior?

Be able to sign URLs when operating under WIF

Possible Solution #1

Catch the exception as it happens, and handle it with an extra API call to signBlob as described here.

There may be pathological performance edge cases, however, since this potentially leads to N api requests when iterating a queryset of records containing files - so there needs to be some careful treatment of that; or a documented process (eg method call) to sign all of a queryset at once, which is slightly different from the usual django pattern of doing it.

Possible Solution #2

relevant (same problem): https://stackoverflow.com/questions/64234214/how-to-generate-a-blob-signed-url-in-google-cloud-run

Workaround

Presently, the simple solution is to use Service Account Credentials for all projects that need to do this.

[thclark]

Also note that this isn't caught by the existing storage test cases; the mocks are too close to the code. Some actual integration tests would slow things down substantially but be of great benefit.

[thclark]

Possibly of relevance: https://github.com/octue/octue-sdk-python/issues/429