Website: Remote SSH Forwarding Example: k8s.io/docs/tasks/access-application-cluster/web-ui-dashboard/#accessing-the-dashboard-ui

[ramzis]

The documentation notes that:

The UI can only be accessed from the machine where the command is executed.

This is not very useful to know when the proxy is running on a remote machine.
A simple solution is to forward the remote dashboard port to your local machine:

ssh -L 8001:127.0.0.1:8001 user@remote

Alternatively, the proxy itself can be configured as kubectl proxy --address='0.0.0.0' --accept-hosts='^*$' and the remote machine (if accessible itself) can indeed be reached directly (credit: https://stackoverflow.com/a/52176544).

Perhaps this could be explained or suggested in the docs if it is not out of scope of "Accessing the Dashboard UI"?

[raghvenders]

@ramzis : I like what you mentioned.Are you mentioning about SSH tunneling?
It is good to mention about that for remote dashboard and view.

[raghvenders]

@ramzis - I tried a PR - https://github.com/kubernetes/website/pull/24035

Just FYI

[maciaszczykm]

As mentioned in the pull request - this is not something that we would advise to the users.

/close

[k8s-ci-robot]

@maciaszczykm: Closing this issue.

In response to this:

As mentioned in the pull request - this is not something that we would advise to the users.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ramzis]

To quote the reply:

This opens an insecure HTTP connection and implicitly allows user to access the API over network, however accessing Dashboard over HTTP is not possible as login view will be blocked. Binding to all interfaces and accepting all hosts is a high security risk. This should not go into official docs.

@floreks What do you mean by "accessing Dashboard over HTTP is not possible as login view will be blocked"? Did you try it?

The whole idea is that there is absolutely no info in the docs (as complained in the stackoverflow link) on how to access the dashboard from a remote machine. You are saying security > any usability. There must be some compromise. The binding to all interfaces is clearly just an example, you could use any or localhost.

Furthermore, the fact that the machine would not necessarily be accessible outside of the ssh connection does not bring any security issue _in my view_, unless you can explain how/why. This is assuming there are no ports forwarded to that machine (except ssh obviously) and there is a working firewall.

[floreks]

@floreks What do you mean by "accessing Dashboard over HTTP is not possible as login view will be blocked"? Did you try it?

It definitely will not work with pure kubectl proxy --address '0.0.0.0' as HTTP connection is only allowed for localhost domains. I have added the code that checks this part.

The whole idea is that there is absolutely no info in the docs (as complained in the stackoverflow link) on how to access the dashboard from a remote machine.

There is. After you provision the cluster, the API server should be accessible from the outside, thus allowing you to execute kubectl proxy (without any arguments) on your client machine where Dashboard should be accessed.

Executing kubectl proxy --address='0.0.0.0' --accept-hosts='^*$' and exposing the whole API for everyone with the privileges of the user executing it is a high-security risk. We can't assume that new users that do not have experience with Kubernetes and don't know other ways of exposing applications such as i.e. using ingresses/load balancer services will have any knowledge about security. For most new users Dashboard is the first thing they are trying and we have to assume that they will just execute these commands without knowing their impact on the security.

If you need to expose it, you can always use the simple NodePort method as described in our docs: https://github.com/kubernetes/dashboard/blob/master/docs/user/accessing-dashboard/README.md#nodeport. It will expose Dashboard over HTTPS on https://<node-ip>:<nodePort>.

[ramzis]

That sounds reasonable 👍. I had not considered the approach with using kubectl outside of the cluster, therefore, the quick solution of tunnelling came to mind.

The info in the link you have provided is very useful, and it would be nice to see it mentioned earlier on in the main docs without needing to scroll down to the bottom to find the github docs and then scroll to find the relevant Accessing Dashboard section.

[floreks]

In the README we provide only the simplest and fastest way of accessing Dashboard. NodePort way is a bit more complicated that is why it is available in the documentation. As you can see even simple command such as:

To access Dashboard from your local workstation you must create a secure channel to your Kubernetes cluster. Run the following command...

can be misinterpreted to think that it should be run on a remote machine instead of your local workstation where Dashboard should be accessed.

[raghvenders]

@floreks - Thanks for the link that helps.kindly help me understand more which of the below holds good?

1.client machine(A) -> kubectl proxy(A) -> browser (A) -> dahsboard(A)

1. client machine(A) -> kubectl proxy(A) -> browser(A) -> dashboard(B)

By the way NodePort is for SingleNode and development purpose.What is the best way for higher environments?

As I see in the document this states better to access dashboard - https://github.com/kubernetes/dashboard/blob/master/docs/user/accessing-dashboard/README.md#api-server

[floreks]

The flow should be:

Browser (A) -> kubectl proxy (A) -> API (B)

NodePort requires you to know ip address of the node where the pod with Dashboard is running. That's why is not so convenient to use. For regular environments it's best to use ingress or Service of type LoadBalancer to expose the application or a combination of some oauth proxy and i.e. dex. Kubernetes Dashboard is no different than any other web app that you'll be running inside your cluster.

[raghvenders]

Gotcha , this is what i feel if we can re-frame current doc sentence as you mentioned above (Looks simple and straight).
If you say it looks good ,i can do a PR#.

You can access Dashboard using the kubectl command-line tool by running the following command:

kubectl proxy

---

(To add) Now the proxy is running at localhost:8001, we see a message << Starting to serve on 127.0.0.1:8001 >>

(To Modify) Kubectl proxy has made the Dashboard accessible at http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.

See kubectl proxy --help for more options.

(To be removed)"The UI can only be accessed from the machine where the command is executed. See kubectl proxy --help for more options."

---

See if those sentences between the lines look better , thanks...

[floreks]

You can also use similar wording to our README:
https://github.com/kubernetes/dashboard#access