0.30.0: "minikube dashboard --url" never completes

[bokysan]

BUG REPORT

Environment:

• Minikube version: minikube version: v0.30.0
• OS: macOS Mojave
• VM Driver: hyperkit
• ISO version: minikube-v0.30.0.iso

What happened:
minikube dashboard --url shows URL and blocks - it doesn't finish properly. It needs to be closed by pressing CONTROL+C.

What you expected to happen:
minikube dashboard --url should show the URL and exit. We are using this command in a script and this blocks the script from moving forward.

How to reproduce it:
minikube dashboard --url

Anything else do we need to know:
This used to work properly at least in version v0.27. I've tracked the issued down to a few of the latest commits on Oct 3. It seems that minikube dashboard now starts a kubectl proxy, which doesn't make much sense in this context.

The process seems to wait for kubectl proxy to finish (without any visual indication in the logs), but it never does. Hence the command never exists.

If kubectl proxy is really needed, does it make sense to have the minikube dashboard --url option at all? Does this mean that dashboard cannot be opened anymore directly by copy/pasting (and bookmarking) the URL? Do we really need the command line to access the dashboard? How does that work if I start minikube dashboard from several consoles or close the console while browsing the dashboard?

While the commit specifies that the change from NodePort to kubectl proxy was done to increase security, I believe that the old way was better and just as secure (at least when running in VM, as it usually binds to local interfaces only and it's not accessible from outside world). If the change cannot be reverted, it should be at least possible to start minikube with old-style binding.

[maxrome]

I started minikube with
sudo minikube start --vm-driver=none

And with minikube dashboard --url I get
http://127.0.0.1:39110/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/

Then it hangs

[tstromberg]

Correct, as a security precaution, as of v0.30.0, the dashboard is now only exposed on-demand, by "minikube dashboard", which in-turn runs "kubectl proxy" underneath to enforce additional security restrictions to prevent DNS repinning attacks. Here's the security advisory:

#3208

If you wish to ignore the security precaution, you may locally reverti the YAML change so that the NodePort is exposed.

Also, the --url option is still useful for tests and those who need to automate dashboard access. Admittedly, with this change, it is not as easy to integrate, since it still needs to be run in the background.

[bokysan]

So, regarding #3208 and this issue -- if I understand it correctly, this could easily be solved by requiring user to specify credentials (username/password) for setting up a dashboard with minikube?

Admittedly, with this change, it is not as easy to integrate, since it still needs to be run in the background.

Exactly. Maybe this could/should be solved in two steps? E.g.
minikube dashboard proxy(which would stay running) and then minikube dashboard to open the actual dashboard.

Either way, IMHO minikube dashboard --url:

• shouldn't start a proxy, at least not automatically
• should exit immediately

I believe the only debate is regarding what would be more proper way of action:

• if --url should exit immediately with an error if no proxy is started, or
• it should return a (proper) URL nevertheless (+ optional warning that the proxy isn't currently started)

Invoking minikube dashboard --url on the command line 100 times should not span up 100 proxies -- user would not expect this command to change the state of the system in any way.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tstromberg]

Closing as not feasible. Requiring users to execute two steps by default just isn't feasible. For security purposes (DNS repinning attacks), the URL should not be guessable, which is why we launch the proxy before hand.

NOTE: As of v0.33, the dashboard service no longer runs by default, so the command command also runs the dashboard service if it isn't running already.

If these security precautions are problematic in your environment - you are welcome to kubectl apply your own dashboard which does not use a proxy. You can then use minikube service to get the correct URL to it.

[bhishekarora]

Closing as not feasible. Requiring users to execute two steps by default just isn't feasible. For security purposes (DNS repinning attacks), the URL should not be guessable, which is why we launch the proxy before hand.

NOTE: As of v0.33, the dashboard service no longer runs by default, so the command command also runs the dashboard service if it isn't running already.

If these security precautions are problematic in your environment - you are welcome to kubectl apply your own dashboard which does not use a proxy. You can then use minikube service to get the correct URL to it.

minikube is hardly used in production, don't see a security issue there. I thought minikube is for testing and learning purpose only.