-
Notifications
You must be signed in to change notification settings - Fork 166
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
Authentication from "gcp" provider #210
Comments
@jeremywadsack can you send a PR for this fix?
You need to re-authenticate with the server using oauth. |
I'm happy to submit a patch but the token is only good for at most an hour.
|
@jeremywadsack for never-expiring tokens you should use service accounts (at least that's what we do in OpenShift). You may have better luck getting this questions answered on the kubernetes repository (there's nothing specific to this gem). |
@simon3z: Right. We use service accounts on the servers. I was trying to set this up to be able to run/test in development where we have I'll go ahead and submit a PR for this as is, with the caveat that you will need to run a I'll dig into kubectl further and check with kubernetes folks about that. |
@jeremywadsack looking at both patches and the google doc you attached I still don't understand the flow 😔 Can you please give a high level flow of what you are trying to achieve? |
@moolitayer Sorry if that wasn't clear. On my dev environment, I'd like to be able to use
I have already authorized PR #211 was the first attempt at this. I saw from the README that I could authorize PR #213 was the second attempt, which uses Google's default application credentials. I think it's the correct solution to this, because it uses the same source credentials that
It has the additional advantage that on GKE I think it will work the same way (because the default application credentials are already installed), without having to specify the location of the Does that help clarify things? |
Just a note that we (myself and @kenazk) ran into this issue. If anyone else hits it and needs a workaround until the linked PRs work there way through into a release you can request GCP gives you the client certificate rather than the new OAUTH token. Simply run the following command:
And then get the credentials again:
The |
Thanks @garethr |
BTW, in our testing of #213, I discovered that it also only works if you've installed default application credentials.
So perhaps, just updating the README with @garethr's suggestion is a simpler approach to solving this, if you are not keen on having this gem support GSC default authentication credentials generally. |
@garethr @jeremywadsack can you send a PR for the README? If there's anything that we can do to facilitate an external/3rd-party integration for gsc please let us know. |
Yes.
Don't you just need to wrap the calls with something that catches the specific error code, re-authenticates and repeats the request? |
Thanks @jeremywadsack and @garethr. I've been super excited about your puppet module but hadn't been able to get it working yet with the 401s, didn't dive into kubeclient until this morning. 👍 |
|
@cben #213 adds support for reading Google's Application Default Credentials, but that's separate from the "gcp" provider for When a Google customer has used
The
Given the details above, how would you feel about a change to Then the instructions in the README would work for
I wouldn't be surprised if this token expiration were true in other environments as well. Maybe there's a way we can expose the token expiration on either the |
sorry for bumping an 1 year old issue, but my team stumbled on the same issue as @jeremywadsack with the gcp provider and the shopify/kubernetes-deploy commands that use @cben would still be desirable to support this? I might take a shot on implementing it, taking some notes from |
@lucasmazza, see #394 (completed) for a step in that direction, at least when application default credentials are present (e.g. in development). Is the issue you had related to refreshing an expired token? See issues #393 for discussion. #400 add notes about how to manually renew. I would support a PR towards auto-renew (although I'm not a maintainer). |
@jeremywadsack @lucasmazza can we close this, has it been covered by #410? |
I'm trying to use
kubeclient
with my local~/.kube/config
file with GKE. Following the instructions in the README I expected this to work as follows:However, this failed because the
Config
class expects theusers
section of the configuration file to contain either atoken
parameter orusername
andpassword
for the appropriate user.When I look at my
~/.kube/config
file it has the following structure for the user auth (key partially redacted):I was able to change
Config#fetch_user_auth_options
to read the access token instead with the following patch:However, this only works until
expiry
. In order to get a new token I have to run akubectl
command and then re-create myKubernetes::Client
.I dug around on this but I can't figure out how
kubeclient
is picking up the new auth token when the one it has stored expired. I'd love to get this working but could use some pointers from anyone who understands this better.The text was updated successfully, but these errors were encountered: