4
votes

Document followed https://docs.aws.amazon.com/eks/latest/userguide/dashboard-tutorial.html

I am able to set up the dashboard and access it using the link http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#!/login

The issue with this is that "EVERY USER HAS TO FOLLOW THE SAME TO ACCESS THE DASHBOARD"

I was wondering if there was some way wherein we can access the dashboard via DomainName and everyone should be able to access it without much pre-set up required.

2
@codeaprendiz I see the provided answer and above link are correct but it's more concept than reproducible solution. I can work on a step by step to help you expose your dashboard more easily if you still need help.Will R.O.F.
@willrof, that would be really great if you could give a step by step solution for this. Thanks in advance.codeaprendiz
@codeaprendiz Hey, I've posted the answer! If it is useful, click the upvote button (▲) to the left of it. If it answers your question, click the checkmark (✓) to accept it. That way others know that you've been (sufficiently) helped. Also see What should I do when someone answers my question? Following these simple rules you increase your own reputation score and at the same time you keep us motivated to answer your questions.Will R.O.F.
@willrof, thanks a lot for such details explanation. I was able to replicate and get my dashboard working :) github.com/codeaprendiz/kubernetes-kitchen/tree/master/gcp/… ... my requirement is to further create IngressRoute (Traefik - docs.traefik.io) so that i can match with a rule like "match: Host(k8s.mydomain.com) && PathPrefix(/dashboard)"codeaprendiz

2 Answers

3
votes

We have two approaches to expose the Dashboard, NodePort and in LoadBalancer.

I'll demonstrate both cases and some of it's pros and cons.


type: NodePort

This way your dashboard will be available in https://<MasterIP>:<Port>.

  • I'll start with Dashboard is already deployed and running as ClusterIP (just like yours).
$ kubectl get service kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes-dashboard   ClusterIP   10.0.11.223   <none>        80/TCP     11m
$ kubectl patch svc kubernetes-dashboard -n kubernetes-dashboard -p '{"spec": {"type": "NodePort"}}'
service/kubernetes-dashboard patched

Note: You can also apply in YAML format changing the field type: ClusterIP to type: Nodeport, instead I wanted to show a direct approach with kubectl patch using JSON format to patch the same field.

  • Now let's list to see the new port:
$ kubectl get service kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   NodePort   10.0.11.223   <none>        443:31681/TCP   13m

Note: Before accessing from an outside cluster, you must enable the security group of the nodes to allow incoming traffic through the port exposed, or here for GKE. Below my example creating the rule on Google Cloud, but the same concept applies to EKS.

$ gcloud compute firewall-rules create test-node-port --allow tcp:31681
Creating firewall...⠹Created [https://www.googleapis.com/compute/v1/projects/owilliam/global/firewalls/test-node-port].                                                                 
Creating firewall...done.                                                                                                                                                               
NAME            NETWORK  DIRECTION  PRIORITY  ALLOW      DENY  DISABLED
test-node-port  default  INGRESS    1000      tcp:31681        False                                                                                                                                                               

$ kubectl get nodes --output wide
NAME                                 STATUS   ROLES    AGE   VERSION         INTERNAL-IP   EXTERNAL-IP
gke-cluster-1-pool-1-4776b3eb-16t7   Ready    <none>   18d   v1.15.8-gke.3   10.128.0.13   35.238.162.157

  • And I'll access it using https://35.238.162.157:31681:

enter image description here


type: LoadBalancer

This way your dashboard will be available in https://IP.

  • Using LoadBalancer your cloud provider automates the firewall rule and port forwarding assigning an IP for it. (you may be charged extra depending on your plan).

  • Same as before, I deleted the service and created again as clusterIP:

$ kubectl get service kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes-dashboard   ClusterIP   10.0.2.196   <none>        443/TCP   15s

$ kubectl patch svc kubernetes-dashboard -n kubernetes-dashboard -p '{"spec": {"type": "LoadBalancer"}}'
service/kubernetes-dashboard patched

$ kubectl get service kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   LoadBalancer   10.0.2.196   <pending>     443:30870/TCP   58s

$ kubectl get service kubernetes-dashboard -n kubernetes-dashboard
NAME                   TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)         AGE
kubernetes-dashboard   LoadBalancer   10.0.2.196   35.232.133.138   443:30870/TCP   11m

Note: When you apply it, the EXTERNAL-IP will be in <pending> state, after a few minutes a Public IP should be assigned as you can see above.

  • You can access it using https://35.232.133.138:

enter image description here


Security Considerations:

  • Your connection to the Dashboard when exposed is always thru HTTPS, you may get a notification about the autogenerated certificate everytime you enter, unless you change it for a trusted one. You can find more here

  • Since the Dashboard is not meant to be much exposed, I'd suggest to keep the access using the Public IP (or custom dns name in case of aws, i.e: *****.us-west-2.elb.amazonaws.com).

  • If you really like to integrate to your main domain name, I'd suggest to put it behind another layer of authentication on your website.

  • New access will still need the Access Token, but no one will have to go thru that process to expose the Dashboard, you only have to pass the IP/DNS Address and the Token to access it.

  • This token has Cluster-Admin Access, so keep it safe as you'd keep a root password.

If you have any doubts, let me know!

0
votes

The deep problem is authentication. If you want the dashboard to respect Kubernetes RBAC rules for the user, it needs their K8s creds and those are usually complicated. For EKS it’s based on your AWS credentials. Some people just put a static set of permissions on the dashboard and then put some other, normal web authentication in front of it.