The connection to the server localhost:8080 was refused

[MOZGIII]

Hello! I have the following behavior:

$ kubectl get nodes
The connection to the server localhost:8080 was refused - did you specify the right host or port?

What should I do to make it work?

OS: Ubuntu 18.04

[grounded042]

Again, sorry for not getting back to you sooner! This is after you've set everything up? Did it ever initiate a login webpage?

[MOZGIII]

What do you mean by initiate? i had to roll back the cluster-side configuration pretty soot after my initial setup attempts cause it started misbehaving.

I should be able to just pass the auth0 settings to kubelet and it's supposed to just work, right? I mean - no additional backend component to deploy is required there?

[grounded042]

Right, no other backend component. After you setup the OIDC support on the API Server (https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server) you should be able to use kubectl as the admin cert will still work.

Then you init your kube config file. After that if you run kubectl get nodes the first time it should open up a browser so you can put in your credentials - that's what I mean by initiate a login webpage. Does it do that?

[MOZGIII]

Ok, that's kind of what I expected, and it didn't do that. I expected a URL to be printed for me to open in a browser, but it didn't happen. I was running kubectl under a proper Ubuntu environment, with X11 and browser set up, so opening a browser should've worked too.

[grounded042]

I have not tested this on Ubuntu - under the hood it's using xdg-open to open the URL - is that installed and does it work if you try it on your own?

[MOZGIII]

Yes, that's what I meant - opening a URL should work. It would be way better to print the URL though - that way it'll be possible to open it manually.

[grounded042]

I've pushed up code in the branch https://github.com/auth0/k8s-pixy-auth/tree/jon/print-auth-url that will print out the URL. Could you test and see if that works for you?

[MOZGIII]

Yeah, why not. I need some time to catch the right moment though.

[MOZGIII]

The issue I got was caused by the fact that I didn't select a cluster. It is nowhere to be found in the documentation, but, in fact, you have to configure cluster settings (API server URL and the certificate).

That said, I now have another error:

$ kubectl get po
Error: could not get access token for auth: could get tokens from the cache: error getting token information from keyring: The collection "k8s-pixy-auth" does not exist. Please add a key first
Usage:
  k8s-pixy-auth auth [flags]
...
<the output above repeats a multiple times, which is not trivial>

The repetitions that I mentioned above are probably caused by retries.

[MOZGIII]

Looks like I got hit by 99designs/keyring#45

[MOZGIII]

I made a PR #18

Tested your URL printing patch, just what I wanted to see there! Browser opens alright though, but for remote ssh sessions it's great (after you map port 8080).

I managed to move forward, but now I got this error: could not get access token for auth: could not exchange code: A non-success status code was receveived: 401

[MOZGIII]

The last step was that I had Auth0 application created as Machine To Machine, while I has to use Native application type.

[MOZGIII]

Finally I got it working, however on Ubuntu it goes through authorization flow via the web browser on every command, which makes it pretty much unusable. I'll create another issue for that.

And this issue has probably a lot of data that should be added to the docs. Also, there are multiple documentation sources - the docs dir and README.md. It would be better if there's only one - to unify the support efforts and reduce confusion.

[MOZGIII]

Regarding the URL printing patch: I think it needs some work on formatting and wording

[grounded042]

Thanks for the research and feedback. This is great! I'll have to take some time to digest some of this and figure out how to best incorporate things. For the docs, we tried to keep things separate and not have Auth0 specific things in the README as we want to show that this can be used for any OIDC provider. We're not trying to create a tool that only works with our offerings.

however on Ubuntu it goes through authorization flow via the web browser on every command

This sounds like it's not caching the credentials which keyring should take care of with at least a fallback to file based caching. This is where the better logging you mentioned would be helpful. Do you know what the expiration time on your tokens is? It could be that you have a low expiration on tokens and it needs to re-auth every time.

[MOZGIII]

Expiration time is usual (default), and even if it was the expiration time issue - I've enabled refresh tokens so that means they're not working too.
I bet the issue if with keychain - it's obviously misbehaving. Frankly, I even have visual glitches - but at this point I'd ask you to step in and check it on your end. This may be a common thing, but it's also possible it's specific to my system.

[grounded042]

I've been using this for a while and I just tested again against minikube without problem. I'll try and spin up a Ubuntu machine to test it out more.

[grounded042]

I've added some clarification to the README about the Auth0 setup as well as some (hopefully) better wording for printing out the auth url: 3d0c6be

Let me know what you think - I'm opening to changing up the wording more.

[MOZGIII]

Commented at commit, overall it looks good now.

[grounded042]

I got this working in a docker container and did not face any problems around the token not working when using it against minikube. I've pushed up how I did that in a markdown file: https://github.com/auth0/k8s-pixy-auth/blob/b218dee6584eb12d0470f337993be74065d4c02c/docs/DockerTestingForUbuntu.md

While testing it out that way I added some small improvements:

• when opening the browser errors it will just print a message telling you to manually open the browser
• if opening the browser doesn't error it will still print out a message in case the browser actually didn't open
• it binds to :8080 not so that it's not restricted to just localhost

Let me know what you think and if this is still causing an error.

[grounded042]

As there has been no update on this ticket in several months I'm going to close it. If this is still an issue you would like to pursue, please comment and re-open the issue.