Kubernetes Dashboard: How to Install, Access & Use It

Last update: July 15, 2026

With apologies to the leet coders in the audience, we're going to make a blunt statement: By and large, working with computers is easier when you have a graphical interface available. Kubernetes Dashboard is a web-based UI for Kubernetes that lets you view and manage cluster resources more easily than relying entirely on kubectl, although it doesn't replace the CLI.

That's why the Kubernetes Dashboard matters to cluster admins and Kubernetes users who want a visual way to check workloads, inspect logs, and handle basic actions without living exclusively at the command line. It can make quick operational tasks faster and simpler, especially if you're less comfortable with kubectl-only workflows, but its functionality is limited: no multi-cluster support, minimal customization, extra resource overhead, and only basic monitoring rather than full observability.

With that reality in mind, let's explore what the Kubernetes Dashboard is, how to install and access it, how its UI is organized, where it falls short, how to troubleshoot common issues, how to handle authentication and security, and how it compares with alternatives and fits alongside kubectl and dedicated observability tools.

What is the Kubernetes Dashboard?

The Kubernetes Dashboard is a Web-based graphical user interface (GUI) and ui for kubernetes clusters. It supports core Kubernetes admin operations, such as launching containers, managing individual Kubernetes resources, and simplifying deployment, monitoring, troubleshooting, and management of Kubernetes applications, while providing a visual overview of cluster health and the status of cluster resources.

The purpose of the Kubernetes Dashboard is to provide an alternative interface to the CLI for folks who manage Kubernetes clusters and applications. Virtually everything that you can do using the Kubernetes Dashboard can also be done using kubectl, the primary CLI tool for administering Kubernetes, and access in the Dashboard is governed through Role-Based Access Control to manage user permissions. But the Kubernetes Dashboard lets you manage the cluster and perform certain tasks without having to write out kubectl commands.

Kubernetes Dashboard disadvantages and security concerns

The Kubernetes Dashboard is a convenient way to manage various aspects of your Kubernetes cluster without having to run kubectl commands. However, it is subject to some distinct drawbacks:

• No multi-cluster support: The Kubernetes Dashboard only lets you manage one cluster at a time. If you have multiple clusters, you'll need to set up a separate Kubernetes Dashboard for each one.
• Limited functionality: The Kubernetes Dashboard offers a fairly broad set of capabilities for viewing information about your Kubernetes resources, as well as performing some basic actions, like creating deployments. But it doesn't support all of the functionality available from kubectl. To perform complex actions, you need to use the CLI.
• Limited customizability: The Dashboard doesn't offer much in the way of customizability. You are limited to the views that are available by default, with some basic filtering options in some cases.
• Overhead: The Kubernetes Dashboard adds to the footprint of your cluster and requires resources to operate. In clusters with limited resource availability, the Dashboard may mean that other workloads will lack sufficient memory and CPU to perform at their best.

For these reasons, you should think of the Dashboard as a tool that can add some convenience to your experience as a Kubernetes admin, but not as a full-scale alternative to CLI tools like kubectl. Even if you make heavy use of the Dashboard, you'll still need to learn to work from the CLI if you want to be an effective Kubernetes admin for most clusters. Kubernetes is simply not designed to be managed through a GUI alone.

In addition, don't think of the Dashboard as a substitute for dedicated Kubernetes observability solutions. The Dashboard provides access to basic monitoring data, like logs, and basic resource consumption based on data from the Kubernetes metrics server. But it doesn't alert you when problems occur, correlate disparate data sources together, or dive deep into performance data to support complex Kubernetes troubleshooting needs. For those tasks, you'll want a complete Kubernetes monitoring and observability solution – and we humbly recommend groundcover.

Kubernetes Dashboard alternatives

If you're reading closely, you'll notice that we're capitalizing the term Kubernetes Dashboard. That's because Dashboard is its official name, but the Kubernetes Dashboard project is deprecated and, as of 2023, no longer actively maintained. It's no longer the default GUI most teams rely on, so favor options that are longer actively maintained for stability and support.

That said, other dashboards for Kubernetes exist. Some Kubernetes distributions and variants, such as Rancher and OpenShift, include built-in custom dashboards (although in most cases, you can also install and run the official Kubernetes Dashboard on those distros if you want). In addition, there are some standalone Kubernetes Web interfaces available, such as Kubernetes Operational View and Lens that provide similar – albeit not identical – functionality to Kubernetes Dashboard.

A comparison of the various Kubernetes dashboards is beyond the scope of this article (which focuses on the official Dashboard), but suffice it to say that you have plenty of options if you're looking for a GUI interface for managing Kubernetes. You're not limited just to Dashboard.

Expert Tip: Treat Kubernetes Dashboard as an Access Layer, Not an Operational Control Plane

Noam Levy Founding Engineer

Noam Levy is a founding engineer at groundcover. Over the last 10 years, Noam has been a part of and led development teams focused on microservices-oriented web applications, monitoring complex application pipelines, and system engineering.

The Dashboard is useful for visibility and light interaction, but should never sit on the critical path of production operations.

• Restrict usage to read-heavy workflows: debugging pods, inspecting resources, quick validation
• Avoid write operations (deployments, config changes) from the UI in production clusters
• Enforce RBAC with least privilege service accounts; never expose cluster-admin tokens broadly
• Disable or tightly control external access; prefer kubectl proxy or short-lived access paths
• Use it as a complement to CLI + GitOps, not a replacement
• Pair with real observability (eBPF-based or metrics+traces) to avoid blind spots in runtime behavior

Kubernetes Dashboard is best positioned as a convenience interface, not a source of truth or control.

Installing the Kubernetes Dashboard

On most Kubernetes distributions, the Dashboard supports only helm based installation as of version 7.0.0.

Use this command to deploy it:

This command downloads and runs the Dashboard based on a container image.

After installing the Dashboard, enable access to it by running:

This starts a proxy server on port 8001 of your local machine. 

Finally, to view the Dashboard, open a Web browser on the node where you started the proxy server and navigate to the following URL:

Accessing the Kubernetes Dashboard

When you log into the Dashboard for the first time, you'll be prompted for an access token, as in this screenshot. Exposing the Dashboard can raise security concerns in production environments, especially if access tokens are overprivileged.

To generate the token, we need to complete a few extra steps (which are documented in full here). First, create a file named dashboard-adminuser.yaml and enter the following code into it:

Be sure to save the file. Next, create another file named dashboard-clusterrolebinding.yaml and enter the following into it:

Save that file as well. Then, run these commands to apply the two manifests you just created:

Finally, run the following command to generate a token:

The output will look something like this:

Copy that code, paste it into the login screen for the Kubernetes Dashboard, and click the Sign in button.

After logging in, you'll see a screen like the following:

This is the "home" screen for the Kubernetes Dashboard.

Using the Kubernetes Dashboard

To use the Dashboard, start by selecting the namespace you want to manage using the dropdown menu. The menu is located to the left of the search bar, near the top of the screen. The Dashboard supports multiple namespaces for isolating workloads and managing resources, and the selected namespace filters which kubernetes objects you see. You can choose a specific namespace, or select the All namespaces option. (The latter approach is convenient because it lets you find all of your resources regardless of the namespace they live in; however, as a best practice, you should avoid selecting All namespaces unless you have a good reason for doing so, because this option makes it easier to make a mistake where you muck up one namespace by deploying resources that you intended for a different one.)

As you can see in the following screenshot, the default view in the Dashboard displays information about active workloads, such as how many DaemonSets, Pods and so on you have running, while also giving visual access to workloads, nodes, namespaces, and configuration settings.

You can also deploy workloads by submitting YAML manifests from the Dashboard.

You can do plenty of other things in the Dashboard, too; this is just an overview of basic functionality. We'll take a more focused look at different parts of the Dashboard in the next section.

Kubernetes Dashboard UI Overview and key features

Now that we've walked through the basic Dashboard functionality, let's dive deeper into key features within it.

Cluster view and cpu and memory usage

If you scroll down the lefthand menu, you'll see a Cluster section. Here, you can access various screens that display data about your cluster as a whole.

Here's a cluster overview: this area provides a visual overview of cluster health and the status of cluster resources, with access controls often enforced at the resource level.

Clicking on different elements will display details about them. For instance, here are details on nodes in my cluster (I have only one node, alas): the Dashboard also shows real-time CPU and memory usage for nodes and pods.

And here's an overview of cluster events: these views help you quickly identify unhealthy pods and deployment failures.

Workloads view

The Workloads section of the Dashboard provides detailed information about Deployments, Pods, and other resources you have running, and it’s where many day-to-day workload management tasks happen as you manage applications running in the cluster.

For example, here are details on Pods:

And you can click on the name of a resource (such as an NGINX Pod, in the following example) to

get even more details about it:

Common tasks here include scaling deployments and restarting pods through the dashboard interface.

If you look toward the upper right of the screen, you'll notice an icon consisting of four horizontal lines. Clicking this will display logs for the Pod, and direct access to logs and related events helps troubleshoot issues faster:

And here's something really cool – you can open a shell directly in the Pod by clicking the button with the horizontal arrow:

The Dashboard also lets you edit live YAML and apply changes immediately.

Discovery and Load Balancing

Under the Service section of the Dashboard, you'll find information about Services and Ingresses that you've configured for your cluster. Dashboard deployments commonly sit behind an ingress controller.

In newer setups, access is often routed through Kong Gateway as a single container in front of the UI, connecting all our containers through a single interface.

Configuration and Storage

The Config and Storage component of the Dashboard details information about storage resources, ConfigMaps, and Secrets; because Secrets may contain sensitive information, access should be protected with network policies and fine grained rbac:

For example, if you want to check on your persistent volume claims, you can click the corresponding tab to view information like the following:

For example, if you want to check on your persistent volume claims, you can click the corresponding tab to view information like the following:

Likewise, you can view a summary of your Secrets, ConfigMaps, and related storage settings as infrastructure-oriented configuration data, especially in on prem environments:

And click a specific Secret to view full details for it:

Troubleshooting the Kubernetes Dashboard

There are a few common errors that you might encounter when getting started with the Kubernetes Dashboard. Here's a look at each one, along with troubleshooting tips.

How to fix page not found or unable to connect to Dashboard

If you can't access the Dashboard at all (in other words, you get a "page not found" or "unable to connect" error) when attempting to navigate to the appropriate URL, there are two likely causes:

• You forgot to start the proxy server: As noted in the Kubernetes Dashboard deployment and installation steps above, you need to run kubectl proxy after installing the Dashboard. Otherwise, it won't be available on your node.
• You are running the Dashboard on a different node: Make sure the node where you installed and ran the Dashboard is the same one where you are trying to access the Dashboard through the browser. If you're unsure which node is which in your cluster, the output of the command kubectl get nodes -o wide may help you map nodes to IP addresses.

How to fix Kubernetes Dashboard forbidden 403 error

If you encounter a "forbidden 403" error when trying to view the Dashboard, it's typically because you don't have a user certificate configured. To fix this error, refer to the section earlier in this article titled “Accessing the Kubernetes Dashboard”. Make sure you've followed the steps there and have properly applied the manifest files in your cluster.

How to fix Kubernetes Dashboard ServiceUnavailable (503) error

A ServiceUnavailable (503) error when trying to access the Dashboard typically means there is an issue with the SSL certificate that the Dashboard needs to encrypt your connection.

A hacky workaround for this error is to install an earlier version of the Dashboard, such as version 1.6.3. Earlier releases don't require SSL.

A better solution, of course, is to make sure you've configured a certificate properly, as well as that you set up a Service for the Dashboard. Try reinstalling the Dashboard again, being sure to follow the steps in the “Accessing the Kubernetes Dashboard” section. Then try accessing the Dashboard again.

Locking down Dashboard authentication and access control

When we installed the Dashboard and set up a user account above, we created an admin user. When logged in using the token that we also generated, the admin has full access to cluster resources and all administration features supported by the Dashboard. Access should instead be restricted with fine grained RBAC at the resource level, rather than relying on broad cluster-wide permissions.

This is, of course, not ideal in scenarios where you want to follow the principle of least privilege (which means granting users only the minimum permissions necessary to do their jobs). In that case, you should probably instead tighten Kubernetes Dashboard authentication and permissions by creating a service account for a user with fewer permissions.

For example, if you want to give a user read-only access to the Dashboard – which would mean the user can view information about the cluster, workloads, and so on, but can't perform actions like creating new deployments – you can set up a manifest like the following and save it to dashboard-read-only-user.yaml. Developers and other users should get only the access needed for their role:

Finally, apply the configuration by running:

Now, you can generate a token for the read-only user with:

And provide that token to the user to log into the Dashboard.

Note that it's possible to configure the Dashboard to support external identity providers, but doing so is beyond the scope of this tutorial.

Kubernetes Dashboard: A powerful but limited tool

We've said it already but we'll say it again: the Kubernetes Dashboard is a handy solution if you want to perform basic admin activities in Kubernetes using a convenient Web interface, a web based ui for Kubernetes clusters rather than a primary control plane.

But the Dashboard is no substitute for kubectl. We know that some folks are squeamish about the CLI, but unfortunately, the Dashboard just doesn't support enough functionality to enable a GUI-only approach to Kubernetes administration.

Nor is the Dashboard a full-fledged Kubernetes monitoring solution – although the good news on this front for the CLI-afraid is that you can use a tool like groundcover to monitor and observe Kubernetes clusters through a convenient GUI interface:

We here at groundcover can't save you from having to learn kubectl to manage Kubernetes workloads. But we can – and do – make it easy to monitor workload and Kubernetes cluster performance using intuitive, user-friendly dashboards.