Install the Kubernetes Dashboard: Step-by-Step

The Kubernetes Dashboard is a powerful way to visualize and manage your cluster, but without proper safeguards, it’s also an open door for attackers. Most “how to install” guides stop at deployment, leaving the dashboard in a dangerously exposed state.

This walkthrough takes a security-first approach: you’ll install the Dashboard via Helm, then immediately lock it down with granular RBAC, dedicated service accounts, and tightly scoped authentication tokens. By the end, you’ll have a Dashboard that’s not just functional, but production-ready.

Key takeaways:

• Secure the dashboard with intentional configuration: The default dashboard installation is not secure. You must actively implement RBAC policies, create dedicated Service Accounts, and use authentication tokens to protect your cluster from unauthorized access.
• Adopt the principle of least privilege: Granting broad cluster-admin access for the dashboard is a significant security risk. Instead, create fine-grained Roles and RoleBindings that give users and groups only the permissions they need to perform their tasks.
• Automate fleet-wide management to scale effectively: Manually configuring dashboards across many clusters is inefficient and introduces risk. A unified platform like Plural centralizes this by providing a single console with built-in SSO, GitOps-driven RBAC, and secure multi-cluster access, eliminating manual toil.

What Is the Kubernetes Dashboard?

The Kubernetes Dashboard is a general-purpose, web-based UI for managing Kubernetes clusters. It provides a high-level view of your cluster’s health, lets you drill into workloads, and helps you troubleshoot issues—without living entirely in kubectl. For multi-cluster operations, having a centralized UI isn’t just convenient—it’s essential for efficiency and consistency.

The open-source Dashboard works well for a single cluster, but securing access, standardizing permissions, and maintaining a consistent view across a fleet adds significant complexity. That’s where a unified management plane comes in. Tools like Plural embed the Kubernetes Dashboard directly into their console, layering on secure SSO, centralized RBAC, and seamless cluster switching—removing the need to juggle kubeconfigs or maintain scattered access rules.

Key Features and Benefits

The main value of the Dashboard is speed and accessibility. Instead of stringing together multiple kubectl commands to troubleshoot a pod, you can click through workloads, view events, and stream logs—all from your browser.

Benefits include:

• Faster triage: Quickly pinpoint failing workloads and inspect events without context-switching.
• Lower barrier to entry: Developers and SREs with limited kubectl experience can still view cluster state and troubleshoot issues.
• Clear resource relationships: Visual layouts help you understand how deployments, services, and storage fit together.

Breaking Down the Dashboard’s Components

The Dashboard organizes resources into logical sections, making the cluster easier to navigate:

• Workloads: View and manage Deployments, Pods, StatefulSets, and Jobs.
• Services & Ingresses: Inspect how applications are exposed to internal and external traffic.
• Storage: See PersistentVolumeClaims and StorageClasses in use.
• Configuration: Access ConfigMaps, Secrets, and other application configs.
• Logs Viewer: Stream logs from any container in real time for debugging.

By turning YAML-defined resources into an interactive interface, the Dashboard makes your cluster more approachable—whether you’re in full operations mode or just checking on application health.

Check Your Prerequisites

Before deploying the Kubernetes Dashboard, make sure your environment is ready—getting this right upfront avoids the common "why can’t I access my dashboard?" headaches later.

1. System Requirements

The Dashboard runs inside your cluster as a web app, so the primary prerequisite is a healthy Kubernetes cluster—local (e.g., Minikube, Kind) or production-grade (AWS EKS, GKE, AKS, etc.).

It’s lightweight, but still consumes CPU and memory. Ensure your cluster has spare capacity so the Dashboard pods don’t compete with workloads. A stable kube-apiserver is also critical—it’s the Dashboard’s data source and control channel.

2. Required Tools and Permissions

The Dashboard isn’t part of a default Kubernetes install. As of v7.0.0, the recommended install method is Helm. You’ll need:

• Helm CLI configured to connect to your cluster
• kubectl for verification and creating RBAC/service accounts
• Cluster admin access, usually a kubeconfig context with cluster-admin rights, so you can create deployments, services, and RBAC roles in the kubernetes-dashboard namespace.

3. Network Access

By default, the Dashboard is internal-only—no public internet exposure. You’ll typically use:

kubectl port-forward svc/kubernetes-dashboard -n kubernetes-dashboard 8443:443

This restricts access to the machine running the command. Authentication uses a Bearer Token tied to a ServiceAccount.

For multi-cluster setups, managing tokens, kubeconfigs, and port-forwarding gets painful fast. Platforms like Plural solve this by embedding a secure, SSO-enabled Dashboard into their console—one login, all clusters, no kubeconfig juggling.

How to Install the Dashboard with Helm

Installing the Kubernetes Dashboard via Helm bundles all the required components into a single, manageable deployment. The process is simple: add the official repository, review your configuration, and run the install command. This is only the foundation, though—securing and streamlining access is the real challenge, especially when scaling to multiple clusters. Platforms like Plural help here by automating deployment and providing a secure, multi-cluster dashboard from the start.

1. Add the Helm Repository

The dashboard’s Helm chart lives in its official repository. Adding it ensures you’re pulling the latest maintained version.

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm repo update

The helm repo update step is essential—it refreshes your local list of charts so you install the most recent release.

2. Review Configuration Options

The defaults will get you a working dashboard, but you should review the chart’s values.yaml before installing. Key settings include:

• Resource requests/limits – Prevent the dashboard from starving other workloads.
• Ingress configuration – Control how (and from where) the dashboard is accessed.
• Extra features – Optional components like metrics or custom branding.

The dashboard routes internal traffic through Kong by default. Understanding these configurations upfront ensures your deployment aligns with your organization’s security and operational standards.

3. Install the Dashboard

Use the helm upgrade --install pattern so you can use the same command for both initial installs and upgrades.

helm upgrade --install kubernetes-dashboard \
  kubernetes-dashboard/kubernetes-dashboard \
  --namespace kubernetes-dashboard \
  --create-namespace

This creates a dedicated namespace to isolate the dashboard from other workloads.

4. Verify the Installation

Once Helm finishes, confirm all pods are running:

kubectl get pods -n kubernetes-dashboard

If everything shows as Running, the dashboard is live inside your cluster.

How to Secure Kubernetes Dashboard Access

The Kubernetes Dashboard is a powerful UI for managing cluster resources—but left unsecured, it’s a glaring security hole. Exposing it without proper safeguards is like leaving kubectl apply --force running on an open terminal.

A secure setup requires three layers:

1. Strong authentication – ensure only verified identities can log in.
2. Granular authorization – enforce least privilege with RBAC.
3. Encrypted communication – protect all dashboard traffic with TLS.

Configuring these manually means creating RBAC policies, provisioning service accounts, managing tokens, and setting up certificates—each a non-negotiable step to prevent cluster compromise. At scale, this gets messy. Platforms like Plural streamline it with an embedded, secured dashboard, SSO integration, and centralized RBAC—so you can manage multiple clusters without reinventing your security stack.

1. Set Up RBAC

Kubernetes RBAC controls who can do what. Never use a default cluster-admin account for daily dashboard access. Instead:

• Define Role or ClusterRole objects with only the required verbs (get, list, create, etc.).
• Bind them to users/groups via RoleBinding or ClusterRoleBinding.

Plural integrates with RBAC through Kubernetes Impersonation, mapping console logins to email or group memberships in your IdP. Example: granting view permissions to the dev-team group via a ClusterRoleBinding means engineers get read-only access—without touching cluster-admin.

2. Create a Service Account

Instead of using personal credentials for dashboard access, create a dedicated ServiceAccount tied to a role:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-sa-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: ServiceAccount
    name: dashboard-sa
    namespace: kube-system

You can then extract its Bearer Token for login. If compromised, revoke it without affecting user credentials.

3. Implement Authentication

The dashboard uses a Bearer Token by default. Tokens tie every action to an identity, but manual token distribution is risky and tedious.

Plural eliminates token handling by integrating with your OIDC provider, letting engineers log in with company credentials while RBAC enforces the right permissions.

4. Configure SSL/TLS

Never expose the dashboard over HTTP. Use cert-manager or a trusted CA to provision a certificate, then configure it in your Ingress or Service manifest.

Plural adds another layer: a reverse tunneling proxy. Your dashboard isn’t exposed publicly—traffic is egress-only from the cluster, tunneled securely to the control plane.

Bottom line: The dashboard is as powerful as it is dangerous. Secure it before you use it—RBAC, service accounts, token management, and TLS are the bare minimum. Platforms like Plural help you enforce these consistently across all clusters without manual overhead.

Best Practices for Kubernetes Dashboard Management

Installing the Kubernetes Dashboard is just the first step—keeping it secure, performant, and useful requires ongoing management. Think of the dashboard as any other application in your cluster: it has a lifecycle, security posture, and resource footprint that need deliberate oversight.

Below are four essential practices to ensure the dashboard remains an asset, not a liability. While you can implement these manually on a single cluster, scaling them across dozens or hundreds of clusters is where manual processes break down. Platforms like Plural can help enforce these best practices fleet-wide from a single console.

1. Harden Your Security

The default Kubernetes Dashboard can be overly permissive. Instead of relying on a single admin account with full control, implement least-privilege access by creating ServiceAccounts with Roles and RoleBindings tailored to specific tasks. This minimizes your attack surface by ensuring users have only the permissions they need.

Plural streamlines this by integrating with your identity provider (IdP) via OIDC. Its embedded dashboard uses Kubernetes Impersonation, allowing RBAC policies to reference user emails and groups from your IdP—making access control intuitive and scalable without juggling tokens.

2. Optimize for Performance

The dashboard consumes CPU and memory like any other workload. In smaller or resource-constrained clusters, unchecked usage can impact application performance. Set resource requests and limits on the dashboard deployment to prevent it from hogging resources.

With Plural, performance overhead is minimized because the heavier UI and API components run in the central control plane, while clusters only run a lightweight CD agent—keeping workload performance intact.

3. Monitor Your Resources Proactively

Use the dashboard’s Workloads, Services, Storage, and ConfigMaps views regularly to catch issues early—like CrashLoopBackOff pods, unbound PersistentVolumeClaims, or misconfigured Services. This helps you fix problems before they cause outages.

For multi-cluster environments, Plural’s unified dashboard provides fleet-wide visibility, letting you monitor and troubleshoot across all clusters without logging into separate UIs.

4. Establish an Update Process

The dashboard receives frequent updates with security patches and features. With manifest-based installs deprecated, Helm is now the recommended method. Manually upgrading with helm upgrade across multiple clusters is inefficient and risky—one missed update can leave you exposed.

Automate updates using GitOps. Store your dashboard’s Helm chart version in a Git repo and let Plural’s CD engine roll out changes across your fleet automatically, ensuring every instance is secure and up to date.

Explore Advanced Configurations

Once you have the Kubernetes Dashboard installed and secured, you’ve built a solid foundation for visibility into a single cluster. However, as your applications and infrastructure grow in complexity, you’ll need to move beyond the default setup. Advanced configurations allow you to tailor the dashboard to your specific operational needs, manage custom workloads, and oversee entire fleets of clusters. This is where the dashboard transitions from a simple monitoring tool to an integral part of your management workflow.

Extending the dashboard’s capabilities often involves working with Custom Resource Definitions (CRDs) to support your unique applications, customizing resource views for better clarity, and figuring out a strategy for multi-cluster management. While these configurations unlock significant power, they can also introduce operational overhead. Each step requires careful implementation to maintain security and stability. For teams managing infrastructure at scale, the goal is to achieve this advanced functionality without creating a patchwork of custom solutions that are difficult to maintain. This is where a unified platform like Plural can be invaluable, providing these advanced capabilities out of the box within a cohesive and secure management console.

Work with Custom Resource Definitions (CRDs)

Custom Resource Definitions (CRDs) are a core Kubernetes feature that lets you define your own resource types. If you run stateful applications, operators, or other complex software, you likely use CRDs to manage them. With CRDs, you can extend the Kubernetes API to handle application-specific logic, allowing you to manage these components with kubectl just as you would built-in resources like Pods or Deployments. While the default Kubernetes Dashboard can list these custom resources, it often lacks the context to display them in a meaningful way, treating them as generic objects. This makes it difficult to get actionable insights without further customization.

Customize Resource Views

To make your CRDs useful within a UI, you need to customize resource views. A generic list of custom resources is a start, but a tailored view that displays the specific status, configuration, and relationships of your custom objects is far more effective. For example, you could configure the dashboard to show the health of a database cluster managed by an operator or the progress of a machine learning pipeline. This level of customization transforms the dashboard from a general-purpose tool into a specialized console for your applications. Understanding Kubernetes CRDs is the first step toward visualizing them effectively and creating a more intuitive operational experience for your team.

Configure a Multi-Cluster View

The standard Kubernetes Dashboard is designed to connect to a single cluster at a time. For teams managing development, staging, and production environments—or running workloads across multiple clouds or regions—this is a significant limitation. Juggling multiple dashboard instances, contexts, and credentials creates friction and increases the risk of human error. While workarounds exist, they often involve complex reverse proxies or third-party tools that add to your maintenance burden.

Plural solves this problem with its built-in multi-cluster dashboard. It provides a single pane of glass to view and manage all your Kubernetes clusters, regardless of where they are hosted. Because it uses a secure, agent-based architecture, you get full visibility without exposing cluster endpoints or managing complex network configurations.

Simplify Dashboard Management with Plural

While the open-source Kubernetes Dashboard offers essential visibility into a single cluster, its utility diminishes quickly as you scale. Managing its deployment, security, and access across a fleet of clusters introduces significant operational overhead. Platform teams find themselves wrestling with version compatibility issues, inconsistent RBAC policies, and the security risks of exposing multiple dashboard endpoints. The manual effort required to configure and maintain each instance is not only time-consuming but also prone to human error, leading to security gaps and operational friction. Juggling different kubeconfigs and browser tabs to switch between clusters becomes a major drag on productivity for developers and operators alike.

Plural addresses these challenges by treating the dashboard not as a standalone tool, but as an integrated component of a holistic fleet management platform. We provide a powerful, secure, and scalable dashboard out of the box, eliminating the manual setup and maintenance burden. This approach transforms your observability workflow, providing a true single pane of glass for monitoring and control without compromising security. By automating configuration and centralizing access, Plural empowers platform teams to provide developers with the visibility they need to be productive, all while enforcing consistent governance and operational best practices across the entire organization.

Unify Your View with a Single Console

Plural provides a single, embedded Kubernetes dashboard that offers a consistent interface for all your clusters, whether they are in different clouds, on-premises, or even on a developer's laptop. This eliminates the need to manage separate kubeconfigs, VPNs, or browser tabs for each environment. The dashboard is not an afterthought; it's deeply integrated with Plural's continuous deployment and infrastructure management capabilities. All traffic to managed clusters uses a secure, egress-only reverse tunnel initiated by the Plural agent, removing the need for complex multi-cloud networking or exposing internal cluster endpoints. This architecture provides full visibility and control from a central console, simplifying troubleshooting and day-to-day operational tasks for your entire team.

Leverage Built-in Security

Security is a foundational component of the Plural dashboard, not an add-on. Access control is managed through Kubernetes Impersonation, which directly maps your console identity—managed via your OIDC provider—to Kubernetes RBAC policies. This provides a seamless and auditable SSO experience. To grant permissions, you simply create standard ClusterRoleBinding or RoleBinding resources that reference a user's email or their group membership. For example, you can grant cluster-admin privileges to your SRE team with a simple manifest. This GitOps-friendly approach ensures that permissions are version-controlled and consistently applied across your fleet, reducing the risk of misconfiguration and unauthorized access.

Automate Configuration and Management

Plural automates the lifecycle of your dashboard configuration, including the RBAC policies that secure it. Instead of manually applying YAML files to each cluster, you can define your fleet-wide RBAC policies in a Git repository and use a Plural GlobalService to automatically sync them everywhere. This ensures that every cluster, new or old, receives the correct, up-to-date permissions without manual intervention. This level of automation extends beyond RBAC. When issues arise, Plural’s AI Insight Engine analyzes logs, events, and resource states to pinpoint root causes directly within the UI, providing actionable recommendations and even suggesting code fixes, turning the dashboard from a passive monitoring tool into an active troubleshooting assistant.

Related Articles

• Plural | Kubernetes Dashboard

Frequently Asked Questions

What is the main difference between the open-source Kubernetes Dashboard and the one Plural provides? The open-source dashboard is designed for a single cluster and requires you to manually handle installation, security, and access for each one. Plural’s dashboard is an integrated part of our fleet management platform, providing a unified, multi-cluster view right out of the box. We automate the difficult parts, like SSO integration and secure networking, so you get a consistent and secure experience across all your clusters without the manual setup.

Why is port-forwarding and using bearer tokens not ideal for team access? While kubectl port-forward and bearer tokens work for individual access to a single cluster, this approach doesn't scale for teams. It requires every user to run commands locally and manually handle sensitive tokens, which is both inefficient and a security risk. If a token is leaked, it could grant unauthorized access. Plural solves this by integrating with your company's SSO, providing secure, auditable access without anyone needing to manage tokens or local proxies.

Do I still need to use kubectl if I have a dashboard? Yes, you should think of the dashboard as a complementary tool, not a replacement for the command line. The dashboard is excellent for quick visual health checks, exploring resources, and making cluster information accessible to team members who aren't kubectl experts. However, kubectl remains essential for automation, complex scripting, and fine-grained control that a UI can't always provide.

How does Plural provide access to a cluster in a private network without exposing it? Plural uses a secure, agent-based architecture. A lightweight agent installed on your cluster initiates an egress-only connection to our central control plane. All dashboard traffic is then securely routed through this established tunnel. This means your cluster never has to expose an inbound port to the internet, allowing you to safely manage private and on-prem clusters from the same unified console.

How does Plural handle RBAC for the dashboard across so many clusters? We integrate directly with Kubernetes Impersonation, which allows you to tie permissions to the user identities in your existing OIDC provider, like Google or Okta. You can write standard Kubernetes RBAC rules that reference a user's email or group membership. By managing these RBAC configurations in Git and syncing them with Plural CD, you can ensure consistent, version-controlled permissions are applied automatically across your entire fleet.