storage: How to use SignedUrl method with workload identity?

[challarao]

Is the SignBytes way to go here? Lib gives an error if we don't pass either private key or SignBytes. There is an appengine example. But how to do it in general. If we use workload identity with kubernetes for example?

Thanks

[challarao]

Does using FindDefaultCredentials work?

https://github.com/golang/oauth2/blob/master/google/default.go#L76

[codyoss]

There are some examples over here that might be what you are looking for:

#1130 (comment)

[derekperkins]

We've been looking into this too. Is that making an RPC call every time you want to sign a URL vs signing it locally if you provide the JSON file? Any idea what the performance / cost tradeoffs are for that?

[OrangeFlag]

FindDefaultCredentials not work on GKE(
golang/oauth2#415

In #1130 (comment) very strange decision on custom libraries hardly suitable for production

[codyoss]

FindDefaultCredentials not work on GKE

It actually does. It will source credentials from the GKE metadata server

In #1130 (comment) very strange decision on custom libraries hardly suitable for production

What do you mean by custom libraries? That example is using our iamcredentials.SignBlob method.

Is that making an RPC call every time you want to sign a URL vs signing it locally if you provide the JSON file

Yes. I would cache the token though and not do this per-signing. If you have access to the json file in your environment I would just use that. The reason the api was used in this example is because you don't have access to the raw key in a workflow identity type of environment, unless you happened to inject it into an environment variable or something.

Closing as I think this sums up the issue.

[derekperkins]

@codyoss You can't sign urls on GKE with Workload Identity out of the box, it requires you to provide a custom json key, which defeats the purpose of WI. Are you suggesting that every user of this library should write their own custom implementation that:

1. creates a custom client wrapper around the storage client
2. makes an RPC call to get a token
3. caches the token in the custom client
4. watches for iam errors
5. on error, blocks all signing requests while a new token is fetched
6. unblocks waiting sign requests

The rest of this SDK silently and asynchronously handles all of that logic, and it doesn't make sense to me why this one very common use case should be exempt from that.

[derekperkins]

cc @carsonoid

[codyoss]

@derekperkins No, I agree that it seems reasonable that we could provide a better user experience here. Off the top of my head I am not sure where this type of changes should be made. Thinking quickly it could happen at three different levels.

1. This could all happen internally just in the storage client.
2. We provide a wrapper to turn a google.Credentials into a crypo.Signer, or something along those lines.
3. google.Credentials could directly have a Sign method directly.

I don't know the complexities here or what other signing user-cases are without more research. I only closed this issue out as it was posed more as a question and not a feature request. I think 1130, already linked above, captures this as a feature request already. Maybe you could drop a note on there if you think there is something in this thread you think is missed over there.

[ellisio]

Hey folks, is there any update or work around for this yet? We don't want to create JSON credentials for every microservice in our infrastructure that needs to create signed URLs for something.

Each service has WI preconfigured, and is used with other Google API needs already. So generating a long lived JSON credential is not ideal.

[codyoss]

@ellisio In the not too distant future I think #4604 will solve this issue. Between using the metadata server and IAM credentials API this usecase should be covered.

[ellisio]

@codyoss Booyah! I'll watch that issue so we can revert the long lived JSON credentials hack once that is released.

[salrashid123]

if it helps, i set up the samples to issue signedurls using workload federation.. both on GKE and 'standalone'.

it seems to be a lot eaiser in go than in other languages...

ptal an let me know if i've missed anything or coudl improve on

• https://github.com/salrashid123/workload_signedurl#signed-url-using-gke-workload-federation