Managing Kubernetes from the command line provides high control, but it is not always the most convenient option for routine checks and troubleshooting.

Kubernetes Dashboard provides a web interface that makes it easier for teams to inspect workloads, resources, and the cluster's current state. To use it securely, however, simply installing it and making it accessible is not enough. Teams also need to plan the access method, the connection to the Kubernetes API, user authentication, and permissions for actions within the cluster.

What Is Kubernetes Dashboard Used For?

Teams can use it to quickly identify unhealthy Pods, check Deployment status, and investigate issues within a specific namespace. This also makes it useful for users who don't work from the command line regularly.

Kubernetes Dashboard (KD or Dashboard in command-line contexts), however, should not replace established processes for managing production environments. Changes to infrastructure and applications should continue to go through GitOps, CI/CD, infrastructure-as-code, and established approval procedures.

It also serves a different purpose from Grafana. While Grafana is primarily used to analyze metrics and performance trends over time, KD shows the current state of Kubernetes resources such as:

• Pods, Deployments, StatefulSets, and Jobs
• Services, Ingresses, and ConfigMaps
• Namespaces, nodes, and storage resources
• Events, logs, and configuration details

Because the interface can expose sensitive information and allow actions based on assigned RBAC permissions, you should control access to it the same way you control access to the Kubernetes API, rather than treating it as a simple web panel.

Is Kubernetes Dashboard Still Maintained?

It has been archived and is no longer actively maintained. Its GitHub repository has been read-only since January 2026, so it is not a good choice for new production environments. Existing installations can remain in temporary use for legacy clusters, ongoing migrations, or short-term operational needs. In these cases, restrict access, keep permissions to a minimum, and plan the transition to a maintained alternative.

If you already have the Kubernetes Dashboard installed and need to continue using it temporarily, use the latest available Helm-based version rather than old manifest-based instructions or legacy YAML, and plan a migration to a supported alternative.

If Dashboard is still in use, follow the current Helm chart rather than outdated manifest-based instructions or legacy YAML. For teams looking for a maintained web interface for Kubernetes, the Kubernetes project recommends Headlamp. A practical approach is to test the new interface in parallel and retire the old Dashboard only after confirming that the required workflows work correctly.

How It Works After Installation

Kubernetes Dashboard is not a standalone application that manages the cluster directly. The installation creates a separate namespace, the required components, and a controlled connection to the Kubernetes API.

Separate Namespace and Helm Management

The standard installation uses the kubernetes-dashboard namespace, which separates Dashboard components from application namespaces. This makes them easier to manage, upgrade, and remove.

The Kubernetes Dashboard Helm chart manages the installation. Helm stores the release configuration and manages resources as a package, rather than relying on manually copied YAML from outdated guides.

Connection to the Kubernetes API

Dashboard does not store cluster state independently. It sends requests to the Kubernetes API, which checks each action against the authenticated identity's permissions.

A gateway or proxy service usually sits in front of the interface and also enables controlled local access through kubectl port-forward.

Access Is Defined Separately from Installation

Installing Dashboard does not grant administrative rights on its own. Service accounts, bearer tokens, and RBAC rules determine what each user can see and change.

How to Secure Access to Kubernetes Dashboard

The right access method depends on whether an individual operator uses Dashboard temporarily or a team needs it to be continuously available.

Local Access with kubectl port-forward

For short-term administrative access, kubectl port-forward is the most suitable option. It connects the local machine to the internal proxy service without exposing Dashboard to the network.

With a standard Helm installation, the connection is typically created with:

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

Dashboard is then available at https://localhost:8443 only from the machine running the command. This model is suitable for troubleshooting, development, and occasional administrative access.

Shared Access Through a Private Ingress

If the Dashboard needs to be used continuously by a team, place it behind a private Ingress accessible only through a trusted network or VPN and protected with TLS.

An additional access proxy or identity provider can control who reaches the interface, but it does not replace Kubernetes RBAC. The proxy manages access to the application, while RBAC determines what each user can see and modify inside the cluster.

Avoid Public Access

Exposing Dashboard through a public LoadBalancer, NodePort, or unrestricted Ingress increases the attack surface and the risk of unauthorized access or token compromise. TLS protects the connection, but it does not compensate for overly broad permissions or weak access controls.

If external access is unavoidable, restrict it with strong authentication, network rules, TLS, audit logging, token management, and least-privilege RBAC.

How Access and Permissions Are Managed

The dashboard uses bearer tokens for login, but a valid token does not provide permissions in the cluster by itself. Kubernetes role-based access control (RBAC) determines what a user can see and change.

Use Separate Service Accounts

Create a service account for a specific role, such as read-only access to a particular namespace. Avoid shared administrator accounts because they make it harder to trace actions, limit permissions, and revoke access.

How RBAC Works

Authentication verifies whether a token is valid, while authorization determines which actions the associated identity can perform.

RBAC uses four main resources:

• Role: Defines permissions within a specific namespace.
• ClusterRole: Defines permissions at the cluster level or for resources outside a namespace.
• RoleBinding: Associates a Role or ClusterRole with an identity within a specific namespace.
• ClusterRoleBinding: Grants permissions from a ClusterRole across the cluster.

Grant Only the Permissions That Are Needed

Start with namespace-level access and grant only the actions required for the specific task. A read-only user, for example, may need access to workloads and logs, while an operator may require limited permissions for scaling or other predefined actions. Cluster-admin should be used only when it is genuinely necessary.

Treat Bearer Tokens Like Passwords

Do not share Dashboard tokens in chat tools, support tickets, repositories, or shared documents. Where possible, use short token lifetimes, revoke access when roles change, and remove unused service accounts and bindings.

How to Assign the Right RBAC Permissions

RBAC should grant access according to the user's actual responsibilities rather than the maximum level of access they might occasionally request. This reduces risk and makes access control easier to manage.

• Read-only support user: Access to Pods, Deployments, Services, events, and logs only in the required namespaces. Secrets should remain inaccessible by default.
• Application operator: May receive limited permissions for specific actions, such as scaling a Deployment in a defined namespace. Production changes should still go through GitOps, CI/CD, and the established change-control process.
• Platform administrator: May require cluster-wide access and access to cluster-scoped resources. Restrict full cluster-admin access to explicitly designated administrators.

Review service accounts, RoleBindings, and ClusterRoleBindings regularly and remove access that is no longer needed.

How to Verify That Access Is Configured Correctly

A successful login does not mean the permissions are configured correctly. Check both how users access the Dashboard and what each user can actually see and change.

• Check the access method: Dashboard should be available only through the approved private access path, such as kubectl port-forward or a protected Ingress.
• Test with least privilege: Use a non-administrative service account and confirm that it can see only the resources it needs.
• Check namespace restrictions: Users should not have access outside their assigned namespaces unless required.
• Test allowed actions: Make sure the user can complete the required tasks but cannot modify unrelated resources.
• Restrict sensitive resources: Secrets should remain inaccessible unless access is explicitly required.
• Review access regularly: Remove unused service accounts and bindings and use audit logs where available.

Repeat these checks after RBAC changes, Helm upgrades, or updates to the Dashboard access method.

How to Troubleshoot Kubernetes Dashboard Access

When Dashboard does not work as expected, first determine whether the problem is related to connectivity, authentication, or RBAC. Avoid using public access or overly broad permissions as a temporary workaround, as this can hide the root cause and increase risk.

• Dashboard does not load: Check the Helm release, proxy service, Pod readiness, and the active port-forward session.
• The token is rejected: Confirm that the token is valid and was issued for the correct service account.
• No resources are visible: Check the Role, ClusterRole, and relevant bindings for the correct namespace.
• A specific action is unavailable: Add only the required RBAC verb (e.g., patch or update) for the specific workload.
• Shared access does not work: Check the private Ingress, VPN, DNS, TLS, and identity proxy configuration.
• The user can see too much: Review RoleBindings and ClusterRoleBindings and restrict unnecessary cluster-wide permissions.

After each change, test again with a least-privilege identity and confirm that the user can complete the required task without receiving additional access.

When to Move to Headlamp

Because Kubernetes Dashboard is no longer actively maintained, it is more practical to plan a transition to a maintained alternative such as Headlamp for long-term use.

The safest approach is to test the new interface in parallel with the current Dashboard while using the same RBAC restrictions and access rules. Verify the main workflows your team relies on and remove the old Dashboard only after the replacement covers the required operational tasks.

The migration is also a good opportunity to review user permissions and remove unnecessary cluster access.

Conclusion

Secure cluster access is only one part of a reliable Kubernetes environment. In a production environment, it is equally important to manage updates, monitoring, backups, network configuration, and incident response effectively.

As the cluster grows, it becomes increasingly difficult for an internal team to manage these tasks consistently. For many organizations, it therefore makes sense to have a specialized provider handle part of infrastructure management while the internal team retains control over applications and deployment processes.

This level of control depends on the wider Kubernetes environment, not only on the interface. At Delta.BG, we manage the infrastructure, security controls, monitoring, and updates required to support secure, production-ready Kubernetes environments. Our Managed Kubernetes service helps teams maintain reliable cluster access while retaining control over their applications and deployment workflows.

For help securing and operating your Kubernetes environment, contact us at support@delta.bg or tel. +359 2 4 288 288.