Minikube: "unauthorized" response to Web UI request.

[KatieLucas-Grapeshot]

Following;

http://kubernetes.io/docs/getting-started-guides/minikube/#starting-the-cluster

Minikube appears to start -- can talk to it, get status, running jobs etc. All looks reasonably sensible.

UI returns a certificate problem of unknown issuer. Fix in Firefox by adding exception and... UI returns single page saying "unauthorized".

In Chrome it says "This site can’t provide a secure connection 192.168.99.100 doesn't adhere to security standards. ERR_SSL_SERVER_CERT_BAD_FORMAT"

Both are running as same user who start minikube.

Search returns matches for people with command-line certification issues but cmdline access works without problems.

Running minikube 0.6.0 on Fedora 23. Docker is known working. Virtualbox version is 5.0.16_RPMFusion. It lists a running "minikubeVM" which looks sensible.

I'm guessing this is a certification issue, but I'm not quite sure where to look further...

[jimmidyson]

I think these are 2 unrelated issues unfortunately. The fact that firefox can hit the dashboard but not auth is weird & I don't really understand why that's happening.

The Chrome cert error is probably a problem with the generated certificate not satisfying Chrome's requirements for a secure enough certificate. Will have to investigate what it's minimum requirements are & make sure we're satisfying them.

[dlorenc]

What URL are you using to hit the dashboard/UI? I don't think we setup HTTPS for the dashboard URL.

[imorti]

yeah have you just tried minikube dashboard? That might be a better
way to get to the dashboard/UI.

On Thu, Jul 21, 2016 at 2:40 PM dlorenc [email protected] wrote:

What URL are you using to hit the dashboard/UI? I don't think we setup
HTTPS for the dashboard URL.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/minikube/issues/379#issuecomment-234345124,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDyLtDNwibCYGGwOJv0DP0D6PHmTz2rks5qX70fgaJpZM4JR4L-
.

[KatieLucas-Grapeshot]

Ah, now "minikube dashboard" works[1] -- http://kubernetes.io/docs/getting-started-guides/minikube/#starting-the-cluster might need updating to mention that instead of some other URLs.

[1] It shows nothing for my user account and under the system page, various system tasks -- which all looks right to me.

[jimmidyson]

The docs do show to use minikube dashboard to access the dashboard. Were you trying to hit https://192.168.99.100:443 by any chance?

[KatieLucas-Grapeshot]

I do apologise -- it does now I know to go look for it.

Confusingly I do get this;

$kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
kubernetes-dashboard is running at
https://192.168.99.100:8443/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard

And that latter URL is what gives out the "Unauthorized"...

But yes, I was expecting one of the outputted URLs to open the dashboard.

On 22 July 2016 at 11:16, Jimmi Dyson [email protected] wrote:

The docs do show to use minikube dashboard to access the dashboard. Were
you trying to hit https://192.168.99.100:443 by any chance?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/minikube/issues/379#issuecomment-234508267,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALks2Acft0HuA-Sr96TyPjPdjGWCYpYDks5qYJhngaJpZM4JR4L-
.

[jimmidyson]

Aha that makes sense. Agree that is confusing. The dashboard URL is using the API server proxy (which requires auth), rather than the service node port (which doesn't). PR would be welcome to do that, or someone else will get to it pretty soon I'm sure.

[jimmidyson]

@KatieLucas-Grapeshot Ah now I see the issue - kubectl doesn't know about minikube (nor should it) so outputs the standard URL to the dashboard. The dashboard actually is accessible there, but as the API server is configured to be secure by default there is no way to authenticate to the dashboard via the API server proxy.

There has been some requests to enable basic auth so you can log in with username/password, but I'm kind of erring towards allowing unauthenticated access. After all this is only a local, dev environment (of course appropriate security should be enabled in production environment). Thoughts @dlorenc?

[dlorenc]

We have to be careful exposing the API server on an unautenticated port. I think that would make it possible for people to craft CSRF attacks in the browser that would make requests to the API server, possibly allowing RCE.

Take a look at this announcement from Docker a few years ago:
https://groups.google.com/forum/#!topic/docker-announce/aQoVmQlcE0A

[dlorenc]

Any ideas here? I think basic auth won't solve the CSRF issue either.

[strahe]

Problem solved?

[dlorenc]

@strahe We haven't made any changes here yet. You can access the API server using kubectl proxy, though.

[KatieLucas-Grapeshot]

Maybe just a change to the docs to emphasise that the printed URL doesn't
work with minikube would be sufficient?

On 3 August 2016 at 04:09, dlorenc [email protected] wrote:

@strahe https://github.com/strahe We haven't made any changes here yet.
You can access the API server using kubectl proxy, though.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/minikube/issues/379#issuecomment-237122479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALks2LJNmVqKyXyQEP0ZSAs0LCuu6rR9ks5qcAZdgaJpZM4JR4L-
.

[omarvides]

@KatieLucas-Grapeshot You could find this useful https://github.com/kubernetes/minikube/issues/522#issuecomment-242273681

[dlorenc]

I think we can close this now that we don't output that URL anymore.

[gishmel]

Are you sure you are not printing this same thing out to the console still? Or do I just have an outdated version of minikube running?

[mnnit-geek]

run command:
kubectl proxy

and then open localhost:8001/ui on the browser

[gishmel]

My only point my posting to this was to tell them they are still printing this information and as the person above said they were no longer I asked for clarification. I understand the correct workflow is to use kubectl proxy.

[galalelatfawy]

just run kubectl proxy --address=clusterIP --port 8001 --accept-hosts '.*'