Table of Contents
What is Kubernetes Dashboard?
It is a general-purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications as well as manage the cluster itself.

You can find more information here:
Deploying with Helm
Pre-requisites
- Helm
- I’m using Helm 2 so in my case I need the Helm client installed on my local machine and Tiller running on my Kubernetes cluster.
- Helm 3 doesn’t use Tiller.
- An Ingress controller and a cert-manager (if you want to use an ingress).
- AWS CLI to get the token we will use to log in.
- jq. Optional. Just to filter the bearer token in the AWS CLI output.
Adding the Helm repo
# Add kubernetes-dashboard repository helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ # Update repo helm repo update
Adding a namespace for the dashboard
This is absolutely optional. I just created a new namespace to deploy the dashboard into.
Create a file called dashboard-namespace.yaml
--- apiVersion: v1 kind: Namespace metadata: name: dashboard labels: name: dashboard
And now create the dashboard by running:
kubectl create -f dashboard-namespace.yaml
Enabling the ingress (and other config changes)
The default configuration options are valid for many people. In my case, I wanted to enable an Ingress so people can access the dashboard easily. This, and all other configuration options are customized using a values file.
Let’s create values.myCluster.yaml
:
--- ingress: enabled: true annotations: kubernetes.io/ingress.class: nginx #This might be different depending on your ingress controller kubernetes.io/tls-acme: "true" #This might be different depending on your cert-manager configuration hosts: - k8s-dashboard.example.com tls: - secretName: k8s-dashboard.example.com hosts: - k8s-dashboard.example.com
Deploying the dashboard
We are now ready to deploy Kubernetes Dashboard to our cluster. Simply run:
#Name, namespace... will change depending on your preference helm install --name k8s-dashboard --namespace dashboard kubernetes-dashboard/kubernetes-dashboard -f values.myCluster.yaml
Update Route53
Since this is a post about EKS I’ll assume you are using Route53.
- Run
kubectl get ingress
on the namespace where you deployed the dashboard. - You should see the ingress we created, make a note of the value under
ADDRESS
. - Create a new A Record aliasing to that value.
You can also uso External DNS and this will be done automatically for you. I’ll write a post about it in the near future.
Once the DNS changes propagate you should be able to connect to Kubernetes Dashboard on that URL.
Logging into Kubernetes Dashboard
If everything went according to plan, you will see a page like this asking you to log in.

There’s many different ways you can restrict access and also different ways to log in. For this example we will use a Bearer Token.
If you have read my previous post about Connecting kubectl to an EKS cluster you might remember all about IAM users and roles, configuring an AWS profile to access the cluster, kubeconfig and so on…
For this example we will assume the profile where credentials allowed to interact with our cluster are kept is my-eks-profile
.
We will retrieve the token using the AWS CLI. For this command you will need the following information:
- Your EKS cluster name (you can find it on your kubeconfig) or on AWS if you have permissions to list clusters, e.g.
my-eks-cluster
. - Your profile, e.g.
my-eks-profile
.
Run the following command:
aws eks get-token --profile my-eks-profile --cluster-name my-eks-cluster
Which will return a JSON document
{ "kind": "ExecCredential", "apiVersion": "client.authentication.k8s.io/v1alpha1", "spec": {}, "status": { "expirationTimestamp": "2020-10-16T07:39:02Z", "token": "k8s-aws-v1.superSecretToken" } }
Copy the token and paste it on the login page to Sing in.
You can pipe the result of the CLI command into jq so you get the token directly.
aws eks get-token --profile my-eks-profile --cluster-name my-eks-cluster | jq -r '.status.token'
And that’s you! Just one last thing, what you can and cannot do once you log in is controlled by the RBAC permissions set for your user/role. If you are an admin (or have similar permissions) you will be able to control the cluster from the Dashboard.
That’s all for now. This was just a very simple introduction to the Kubernetes Dashboard on EKS. There’s plenty of things you can change and I haven’t covered. Authentication and permissions is the first thing that comes to mind, you can create a service account with whatever permissions you choose and use the secret it generates instead of the token generated by the AWS CLI, or you prefer basic auth…
As usual, thank you for visiting my blog! I hope this was useful for you. Please, let me know in the comments below. Have you got any questions? Ask!