Exposing Dashboard To Internet

General Discussions
1

Hello guys.
I have a cluster in AWS , I inherited that, did not installed, is working fine for some purposes and it also has a dashboard installed but is not working so I have to make it work, all the documents talk about executing proxy command and then access it to localhost, that’s not what I want, I also executed the following:

Preformatted textkubectl proxy --address=‘0.0.0.0’ --port=8001 --accept-hosts=‘^*$’

With that I can access it over the Public IP:
Preformatted text1.1.1.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login

I get prompted with a token , I provide a token but it does not work, then I found this documentation, where it states the following:

Preformatted textHome · kubernetes/dashboard Wiki · GitHub
NOTE: Dashboard should not be exposed publicly using kubectl proxy command as it only allows HTTP connection. For domains other than localhost and 127.0.0.1 it will not be possible to sign in. Nothing will happen after clicking Sign in button on login page.

That’s what happening to me , when I hit sigg in it does nothing, so Im new to k8s, does anyone have any document or guide to publish the dashboard to the public?

I also changed the dashboard configuration from NodePort to LoadBalancer, then I had something like this:

Blockquote

kubernetes-dashboard LoadBalancer 10.x.x.x a0b0503020e8b11e9dfdfdfeb0be4-12533333444.eu-west-1.elb.amazonaws.com 443:31269/TCP

When I try to access that public IP and port 31269 it does nothing, is that because I need to change something on a Security Group?

What I also noticed from the logs when enabling LoadBalancer more where these errors:

2019/02/23 03:34:12 http: TLS handshake error from 192.168.x.x:12342: EOF
2019/02/23 03:34:14 http: TLS handshake error from 192.168.x.x:64896: EOF
2019/02/23 03:34:19 http: TLS handshake error from 192.168.x.x:10616: EOF

Thanks in advanced.
Regards

2

If your exposing the dashboard be very careful of how you do it you don’t want to accidentally expose too much.

Here’s a really good article from Joe Beda of Heptio (and Kubernetes fame) on how to secure and expose the dashboard, https://blog.heptio.com/on-securing-the-kubernetes-dashboard-16b09b1b7aca . He recommends using an authentication proxy and strongly suggests avoiding the LoadBalancer method for security reasons.

Hope that helps!

3

Thanks, so you advice that the safest way is to access it to the cluster IP within a VPN connection?
Is that possible without executing kubectl proxy command ? The idea is not to grant ssh access to the user to execute commands.

Thanks
Regard

4

I think the safest way to expose the dashboard publicly is via the oauthproxy method outlined in the article. You will want to try to insulate it as best as possible especially if your users don’t have access to kubectl to proxy the dashboard.

Is there a reason in particular the other admins need to ssh in to use kubectl and what is the requirement for the dashboard?

5

Hello.

I was granted admin access to troubleshoot it and make it work, the EKS is on AWS, and a couple of guys from Development team need access to the console to troubleshoot some deployments, some pods issues, maybe I can solve this another way, creating some roles on IAM for example.

I do not know either if from AWS they can have some kind of access to it, and what is more, the examples found on AWS documentation refer to using kubectl proxy command and accessing it on localhost and I think this is because of all the security concerns related to exposing it to the outside.

Thanks
Regards

6

I saw some documentation the other week about creating IAM accounts and using them with Kubectl. I will try to dig that up today that would let users get access to he dashboard on their local systems.

7

Okay that makes sense. I think just granting them access via kubectl (installed on their machines) would be the best bet and then they can use kubectl proxy if they need the dashboard. That way you don’t have to worry about exposing it.

This will guide you through installing kubectl on a local system and granting access to that user with an IAM account, here . I haven’t had the chance to try out EKS yet so I hope that works. If you you bump into any specific issues you may want to drop in on #sig-aws in the k8s slack.

Here are a couple other articles I thought might be useful

8

Thank you very much, I’ll take a look.

Best regards