LehnerBuild

Programming

How to sign in kubernetes dashboard

25 September 2026 · 8 min read

How to sign in kubernetes dashboard

The Kubernetes Dashboard provides a web-based user interface that allows you to deploy containerized applications, monitor their status, troubleshoot issues, and manage Kubernetes resources. While incredibly powerful for managing your cluster, one of the most common hurdles new users face is figuring out exactly how to sign in Kubernetes dashboard securely and efficiently. Unlike traditional web applications with straightforward username/password fields, accessing the Kubernetes Dashboard requires specific authentication mechanisms, primarily relying on tokens associated with Service Accounts. Mastering this process is crucial for anyone looking to leverage the full potential of their Kubernetes environment, ensuring both ease of access for administrators and robust security for the cluster’s sensitive operations. This guide will walk you through the necessary steps to gain secure access, transforming a potentially complex task into a manageable one for any Kubernetes operator.

Understanding Kubernetes Dashboard Access Methods

Gaining access to the Kubernetes Dashboard isn’t a one-size-fits-all process. Kubernetes, by design, prioritizes security, meaning direct, unauthenticated access is generally not permitted or recommended. The primary methods for accessing the dashboard involve using either a temporary proxy or a more permanent token-based authentication. Each method serves different purposes and comes with its own set of security implications and setup requirements. Understanding these distinctions is fundamental to choosing the right approach for your operational needs, whether it’s for quick diagnostics or ongoing cluster management.

Historically, there have been ways to expose the dashboard directly via NodePort or LoadBalancer services, but these are largely discouraged due to significant security risks, especially in production environments. The recommended and most secure approaches leverage Kubernetes’ built-in authentication and authorization mechanisms, specifically Role-Based Access Control (RBAC) and Service Accounts. These methods ensure that only authorized users or systems can interact with the dashboard, preventing unauthorized access to your critical infrastructure. The emphasis on RBAC means you have granular control over what a user or service account can see and do within the dashboard, aligning perfectly with the principle of least privilege.

Access via kubectl proxy

For quick and local access, especially during development or troubleshooting, the kubectl proxy command is an excellent tool. It creates a proxy between your local machine and the Kubernetes API server, allowing you to access the dashboard through your browser without exposing it directly to the public internet. This method is often the simplest way to get started and is generally secure because the connection is local and relies on your existing kubeconfig credentials for authentication with the API server. When you run kubectl proxy, it typically makes the dashboard available on http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/, though the exact URL might vary slightly based on your installation.

While convenient, kubectl proxy is temporary. The connection is severed when the command is terminated, making it unsuitable for continuous or multi-user access. It’s primarily designed for individual administrators to interact with the dashboard from their local environment. This method also inherits the permissions of the user running the kubectl command, so ensuring your kubeconfig is configured with appropriate RBAC roles is crucial. For instance, if your user only has read-only access to certain namespaces, the dashboard accessed via kubectl proxy will reflect those same limitations.

Service Account Token-Based Authentication

For more persistent and secure access, especially in multi-user or production environments, token-based authentication using Kubernetes Service Accounts is the preferred method. This approach involves creating a dedicated Service Account, assigning it specific RBAC permissions, and then extracting a bearer token associated with that Service Account. This token can then be used to log into the Kubernetes Dashboard, providing a robust and auditable method of user authentication. This method allows for fine-grained control over what specific users or teams can do within the dashboard, adhering strictly to security best practices.

To sign in Kubernetes dashboard using a token, you’ll first need to create a ServiceAccount, define appropriate ClusterRoles and ClusterRoleBindings to grant it the necessary permissions, and then retrieve the secret token associated with that ServiceAccount. This bearer token acts as the credential you’ll input into the dashboard’s login page, providing secure and controlled access based on the RBAC policies you’ve defined. This ensures that even if the token is compromised, its permissions are limited, minimizing potential damage. Organizations often use this method to provide different levels of access (e.g., read-only for developers, full access for operations) to various teams accessing the same dashboard instance.

Step-by-Step: Setting Up a Service Account for Dashboard Access

Setting up a Service Account for Kubernetes Dashboard access involves several distinct steps, each critical for ensuring both functionality and security. This process leverages Kubernetes’ native RBAC system to define exactly what permissions the Service Account will have, thereby controlling what actions can be performed through the dashboard. It’s important to follow these steps carefully to avoid over-privileged access, which can pose a significant security risk to your cluster. This guide assumes you have kubectl configured and working correctly with your Kubernetes cluster.

The core idea behind this method is to create an identity (the Service Account) within Kubernetes, grant it specific permissions (via a ClusterRole), and then bind those permissions to the identity (via a ClusterRoleBinding). Once this is established, Kubernetes automatically creates a secret containing a bearer token for that Service Account. This token is what you’ll ultimately use to authenticate with the Kubernetes Dashboard. This structured approach provides a clear audit trail and allows for easy revocation of access if needed, simply by deleting the associated Service Account or its binding.

  1. Create a Service Account: First, define a Service Account in the kubernetes-dashboard namespace (or another namespace if your dashboard is deployed differently). This Service Account will be the identity used for dashboard access. ``` kubectl create serviceaccount dashboard-user -n kubernetes-dashboard
  2. Create a ClusterRole (or Role) for Dashboard Access: Define the permissions this Service Account will have. For full administrative access, you might bind it to an existing cluster-admin ClusterRole, but for production, it’s highly recommended to create a custom, more restricted ClusterRole. For demonstration, we’ll use a pre-existing one. ``` kubectl create clusterrolebinding dashboard-user-cluster-admin –clusterrole=cluster-admin –serviceaccount=kubernetes-dashboard:dashboard-user 
    
**Note:** Binding to `cluster-admin` grants full control over your cluster and should be used with extreme caution. For production, define a custom `ClusterRole` with only necessary permissions, e.g., for viewing resources.
  3. Get the Bearer Token: After creating the Service Account and binding it to a role, Kubernetes automatically creates a secret containing the bearer token. You need to find the name of this secret and then extract the token. ``` TOKEN_NAME=$(kubectl get secrets -n kubernetes-dashboard -o jsonpath="{.items[?(@.metadata.annotations[‘kubernetes.io/service-account.name’]==‘dashboard-user’)].metadata.name}") kubectl get secret $TOKEN_NAME -n kubernetes-dashboard -o jsonpath="{.data.token}" | base64 -d 
    
Copy the outputted token. This is your credential to log into the dashboard.
  4. Access the Dashboard: Start kubectl proxy (if you haven’t already done so) and navigate to the dashboard URL in your browser. Select the “Token” option and paste the copied token into the input field. Click “Sign In.” ``` kubectl proxy 
    
Then **Question & Answer :**

I just upgraded kubeadm and kubelet to v1.8.0. And install the dashboard following the official [document](https://github.com/kubernetes/dashboard).
    $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml 
    
After that, I started the dashboard by running
    $ kubectl proxy –address=“192.168.0.101” -p 8001 –accept-hosts=’^*$’ 
    
Then fortunately, I was able to access the dashboard thru <http://192.168.0.101:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/>

I was redirected to a login page like this which I had never met before. [![enter image description here](https://i.sstatic.net/5dy2F.png)](https://i.sstatic.net/5dy2F.png) It looks like that there are two ways of authentication.

I tried to upload the `/etc/kubernetes/admin.conf` as the kubeconfig but got failed. Then I tried to use the token I got from `kubeadm token list` to sign in but failed again.

The question is how I can sign in the dashboard. It looks like they added a lot of security mechanism than before. Thanks.


> As of release 1.7 Dashboard supports user authentication based on:
> 
> 
> - [`Authorization: Bearer <token>`](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#authorization-header) header passed in every request to Dashboard. Supported from release 1.6. Has the highest priority. If present, login view will not be shown.
> - [Bearer Token](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#bearer-token) that can be used on Dashboard [login view](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#login-view).
> - [Username/password](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#basic) that can be used on Dashboard [login view](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#login-view).
> - [Kubeconfig](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#kubeconfig) file that can be used on Dashboard [login view](https://github.com/kubernetes/dashboard/blob/v2.0.0/docs/user/access-control/README.md#login-view).

— [Dashboard on Github](https://github.com/kubernetes/dashboard)

Token
-----

Here `Token` can be `Static Token`, `Service Account Token`, `OpenID Connect Token` from [Kubernetes Authenticating](https://kubernetes.io/docs/admin/authentication/), but not the kubeadm `Bootstrap Token`.

With kubectl, we can get an service account (eg. deployment controller) created in kubernetes by default.
    $ kubectl -n kube-system get secret # All secrets with type ‘kubernetes.io/service-account-token’ will allow to log in. # Note that they have different privileges. NAME TYPE DATA AGE deployment-controller-token-frsqj kubernetes.io/service-account-token 3 22h $ kubectl -n kube-system describe secret deployment-controller-token-frsqj Name: deployment-controller-token-frsqj Namespace: kube-system Labels: Annotations: kubernetes.io/service-account.name=deployment-controller kubernetes.io/service-account.uid=64735958-ae9f-11e7-90d5-02420ac00002 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1025 bytes namespace: 11 bytes token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkZXBsb3ltZW50LWNvbnRyb2xsZXItdG9rZW4tZnJzcWoiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVwbG95bWVudC1jb250cm9sbGVyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiNjQ3MzU5NTgtYWU5Zi0xMWU3LTkwZDUtMDI0MjBhYzAwMDAyIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRlcGxveW1lbnQtY29udHJvbGxlciJ9.OqFc4CE1Kh6T3BTCR4XxDZR8gaF1MvH4M3ZHZeCGfO-sw-D0gp826vGPHr_0M66SkGaOmlsVHmP7zmTi-SJ3NCdVO5viHaVUwPJ62hx88_JPmSfD0KJJh6G5QokKfiO0WlGN7L1GgiZj18zgXVYaJShlBSz5qGRuGf0s1jy9KOBt9slAN5xQ9_b88amym2GIXoFyBsqymt5H-iMQaGP35tbRpewKKtly9LzIdrO23bDiZ1voc5QZeAZIWrizzjPY5HPM1qOqacaY9DcGc7akh98eBJG_4vZqH2gKy76fMf0yInFTeNKr45_6fWt8gRM77DQmPwb3hbrjWXe1VvXX_g 
    
Kubeconfig
----------

The dashboard needs the user in the kubeconfig file to have either `username & password` or `token`, but `admin.conf` only has `client-certificate`. You can edit the config file to add the token that was extracted using the method above.
    $ kubectl config set-credentials cluster-admin –token=bearer_token 
    
Alternative (Not recommended for Production)
============================================

Here are two ways to bypass the authentication, but use for caution.

Deploy dashboard with HTTP
--------------------------
    $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/alternative/kubernetes-dashboard.yaml 
    
Dashboard can be loaded at <http://localhost:8001/ui> with `kubectl proxy`.

Granting admin privileges to Dashboard's Service Account
--------------------------------------------------------
    $ cat «EOF | kubectl create -f - apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: kubernetes-dashboard labels: k8s-app: kubernetes-dashboard roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: kubernetes-dashboard namespace: kube-system EOF 
    
Afterwards you can use <kbd>Skip</kbd> option on login page to access Dashboard.

If you are using dashboard version v1.10.1 or later, you must also add `--enable-skip-login` to the deployment's command line arguments. You can do so by adding it to the `args` in `kubectl edit deployment/kubernetes-dashboard --namespace=kube-system`.

Example:
    containers: - args: - –auto-generate-certificates - –enable-skip-login # <– add this line image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1