Skip to content
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

0.30.0: "minikube dashboard --url" never completes #3236

bokysan opened this Issue Oct 9, 2018 · 5 comments


None yet
5 participants
Copy link

bokysan commented Oct 9, 2018



  • 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.

@tstromberg tstromberg changed the title "minikube dashboard --url" never completes 0.30.0: "minikube dashboard --url" never completes Oct 9, 2018


This comment has been minimized.

Copy link

maxrome commented Oct 10, 2018

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

And with minikube dashboard --url I get

Then it hangs


This comment has been minimized.

Copy link

tstromberg commented Oct 11, 2018

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:


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.


This comment has been minimized.

Copy link

bokysan commented Oct 15, 2018

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.


This comment has been minimized.

Copy link

fejta-bot commented Jan 13, 2019

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


This comment has been minimized.

Copy link

tstromberg commented Jan 23, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.