The Kubernetes Dashboard Is Archived: What It Means and Where to Go Next

On 21 January 2026 the Kubernetes Dashboard repository was archived. It now lives at kubernetes-retired/dashboard, it accepts no pull requests, and it will never receive another security patch.

If that is the first you are hearing of it, you are not unusual. The Dashboard was one of those components that gets installed once during cluster setup and then never thought about again — which is exactly what makes this worth an afternoon of your time.

What actually happened

The Kubernetes SIG UI group archived the project because it ran out of active maintainers and contributors. That is the whole story. No security incident, no dramatic rewrite — just the ordinary way open source projects end when nobody is left to review the pull requests.

Three things followed:

• The repository moved to the kubernetes-retired GitHub organisation. Issues and pull requests are closed.
• SIG UI named Headlamp as the successor project. Headlamp now lives under kubernetes-sigs and is Apache 2.0 licensed.
• The Kubernetes project published a transition explainer on 1 June 2026, followed by a step-by-step migration guide on 13 July 2026.

The interesting part is not the migration path. It is what "archived" means for something already running in your cluster.

This is a security problem, not housekeeping

An archived project does not stop working. That is the trap. Your Dashboard will keep serving pages for years, and nothing in your monitoring will tell you it has quietly become a liability.

Here is why it has.

Any vulnerability found from now on stays open. Not "patched slowly" — never patched. There is no maintainer to triage a report, no release process to ship a fix, and no version to upgrade to. The CVE database will keep accepting entries. The project will not act on them.

The Dashboard is a privileged workload. It exists to read and modify cluster resources, so it runs with a service account that has real permissions. In a lot of clusters — more than anyone likes to admit — that service account got bound to cluster-admin during a frustrated debugging session and was never narrowed again. An unpatchable web application with cluster-admin is a genuinely bad combination.

It is frequently reachable. Some teams put it behind an Ingress for convenience. Others rely on kubectl proxy and assume that is safe because it is local. Both are defensible when the software is maintained. Neither is defensible indefinitely.

It will surface in your next audit. SOC 2, ISO 27001 and PCI-DSS all expect you to run supported software and to remediate known vulnerabilities inside a defined window. "The upstream project is archived and we kept it anyway" does not survive a control review.

First, find out whether you are still running it

Most people are less certain than they think. Check every cluster, not just the ones you remember building:

# The upstream manifests label their workloads
kubectl get deploy,svc,sa -A -l k8s-app=kubernetes-dashboard

# The default namespace from the standard install
kubectl get all -n kubernetes-dashboard

# What the Dashboard's service account was actually granted
kubectl get clusterrolebinding -o wide | grep -i dashboard

Pay attention to that last one. If it prints cluster-admin, deal with it today regardless of what you decide about replacing the UI.

Where to go: three honest options

Option 1 — Headlamp, the official successor

Headlamp is what SIG UI points you at, and it is a sound recommendation. Apache 2.0, hosted under kubernetes-sigs, and it runs either in-cluster as a web app or on your desktop. Unlike the old Dashboard it is RBAC-aware in a meaningful way: the interface reflects what your credentials actually permit, so actions you cannot perform are not offered to you.

What carries over: the mental model. Browsing namespaces, workloads, pods, logs and events works the way you expect it to.

What is better: multi-cluster views are built in, there is a Projects concept for grouping resources across namespaces and clusters, and the plugin ecosystem on Artifact Hub is active — including community plugins for Trivy, Kyverno and Kubescape, plus an AI Assistant plugin that is still marked alpha.

What is honest to say about the gap: Headlamp is a user interface. It has no alerting, no on-call scheduling and no compliance reporting. Security scanning exists only to the degree that you adopt and maintain the plugins for it. If the Dashboard was the only operational tool in your cluster, Headlamp replaces it faithfully — but it does not close the gaps the Dashboard also had.

You also inherit the responsibility you just learned about the hard way. Headlamp is self-hosted software that talks to your Kubernetes API, and it needs the same patching discipline as anything else in that position.

Option 2 — A desktop client

Lens, K9s, Aptakube and K8Studio remove the in-cluster attack surface entirely. There is no web application running in your cluster to exploit, because the tool lives on your laptop and talks to the API server the way kubectl does.

For a small team that is a real improvement over an unmaintained in-cluster Dashboard, and it may be the fastest correct answer.

The trade is that it moves the risk rather than removing it. Every engineer now needs a kubeconfig on local disk, so the number of machines holding working cluster credentials equals the size of your team. There is also no shared state — no common dashboard, no shared history, and nothing an auditor can be shown.

Option 3 — An operations platform

If the honest answer to "why did we have the Dashboard" is "so someone could look at the cluster when something broke", then replacing it with another viewer solves the smaller half of the problem.

This is where SRExpert sits, and we will be direct about the trade: it is a paid product and Headlamp is free. What you get for the money is the layer that teams rarely finish assembling — continuous CIS scanning mapped to SOC 2, HIPAA, PCI-DSS and ISO 27001, CVE and exposed-secret detection, alert deduplication with on-call rotations attached, and 6+ AI models with cluster context — as one maintained product instead of six you version separately. Engineers sign in through SSO rather than holding kubeconfigs, and for isolated clusters an in-cluster agent connects outbound, so no inbound firewall port is ever opened.

Choosing between them

There is no single right answer. A platform team with spare capacity should probably run Headlamp and be perfectly happy. A two-person team with a SOC 2 deadline probably should not spend the next quarter assembling a security stack around it.

A migration checklist

Whatever you pick, do these in order:

1. Inventory. Run the commands above against every cluster, including the ones nobody claims ownership of.
2. Fix the RBAC first. If the Dashboard service account holds cluster-admin, remove that binding now. This is independent of which UI you end up with, and it is the highest-value ten minutes in the whole exercise.
3. Deploy the replacement side by side. Do not delete the old Dashboard on day one. Put the new tool next to it and let people use both for a week.
4. Cut the ingress before the workload. Removing external exposure is the change that actually reduces risk; deleting the pods is bookkeeping.
5. Delete the workload and its RBAC. Deleting the namespace leaves ClusterRoleBindings behind. Remove those explicitly.
6. Write it down. Record the removal date somewhere your auditor will find it. "Unsupported component identified and removed" is a far better finding than silence.

The lesson worth keeping

The Dashboard did not fail. It was quietly abandoned, it kept running, and the risk accumulated inside a component nobody had looked at in three years.

That pattern is not unique to the Dashboard. It is worth asking what else in your clusters is in the same position — installed once, never upgraded, still holding permissions someone granted in a hurry. The answer is usually longer than expected.

If you would rather have that answered continuously than during your next audit, start SRExpert free for 30 days — the full platform, no credit card required.