-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
storage: How to use SignedUrl method with workload identity? #2915
Comments
Does using FindDefaultCredentials work? https://github.com/golang/oauth2/blob/master/google/default.go#L76 |
There are some examples over here that might be what you are looking for: |
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? |
FindDefaultCredentials not work on GKE( In #1130 (comment) very strange decision on custom libraries hardly suitable for production |
It actually does. It will source credentials from the GKE metadata server
What do you mean by custom libraries? That example is using our iamcredentials.SignBlob method.
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. |
@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:
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. |
cc @carsonoid |
@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.
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. |
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 Booyah! I'll watch that issue so we can revert the long lived JSON credentials hack once that is released. |
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 |
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
The text was updated successfully, but these errors were encountered: