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
Unable to generate signedUrl when using WIF under GKE #2447
Comments
Hi @mkherlakian in your description you mention using |
Hey @ddelgrosso1! Apologies, I did test a few versions. The Stack trace was indeed from 6.12 but 7.10 behaves the same! |
@mkherlakian could you possibly test with v7.10 and provide me the output of |
Sure thing @ddelgrosso1 - here goes:
BTW I did replace test_account in the output, the account we're using is a combination of letters and numbers, and one hyphen, in case that makes a difference.
|
Just an update, I setup a GKE cluster today and was able to recreate the same error. I'm still trying to figure out if it is a configuration problem with WIF / GKE (full disclosure I'm not a GKE expert by any means) or a problem in the auth library. Will update once I get to the root cause. |
Thanks for the update! It's good that it's reproducible. Yeah the strange thing is that other operations seem to work fine. I guess the mechanism for signed url is possibly different?... Let me know if I can help! |
So I got this working today. Turns out some adjustments are needed on both the setup / configuration of GKE and on the code side. I'm going to link to this repo which is not google owned but does a much better job walking through the relevant setup than I can. The relevant Node bits are here. Edit: I'm going to take an action item to discuss this internally and see what we can do about better documenting this officially. |
Thanks for taking a look at this @ddelgrosso1. Just went through the repos you linked, what they're doing does make sense. Is there no way to transparently support this from the library, without having to create a user impersonation? It does add quite a bit of friction to the process, and might lead users to just inject a |
@mkherlakian fair question. From the perspective of the storage library I'm not sure what, if anything could be done to make this more transparent. This library hands the actual signing call off to the authentication library which in turn handles the metadata calls. I think the larger gap here isn't necessarily the way storage or auth behaves but rather the docs don't clearly illustrate how to get this properly setup. The auth library has some samples on using the Impersonated client but there is still a lack of end to end setup documentation. |
@mkherlakian curious if you were able to get this to work? |
Going to close this out. If there are more questions or problems, feel free to reopen or start a new issue. |
Environment details
@google-cloud/storage
version: 7.10Steps to reproduce
Resulting error:
getSignedUrl
with Workload Identity #1672 and "Failure from metadata server" when using GKE and Workload Identity #2346 which have no solution.The text was updated successfully, but these errors were encountered: