Headlamp Dashboard: Deep Dive

This document explains what makes Headlamp different from other Kubernetes dashboards, why its authentication model matters, and when it is the right choice for your team.

What CNCF Sandbox Means

Headlamp is a CNCF Sandbox project. That label tells you several things.

The Cloud Native Computing Foundation (CNCF) accepts projects at three levels: Sandbox, Incubating, and Graduated. Sandbox is the entry point. It means the CNCF considers the project promising and aligned with cloud-native principles, but it has not yet proven broad adoption or production maturity.

For you as a user, Sandbox means: the project is real, has community backing, and follows open governance. It also means the API and feature set may still change. Kubernetes itself is a CNCF Graduated project. Headlamp is earlier in that journey.

Why does this matter? When choosing tools for a team, CNCF status signals that the project is not a single-maintainer side project that could disappear tomorrow. It has organizational support and a path toward maturity.

Token-Based Authentication

Headlamp requires a token to log in. This is its most important difference from YAKD and many other dashboards.

When you access Headlamp, you see a login screen asking for a bearer token. You generate this token from a Kubernetes ServiceAccount:

kubectl create serviceaccount headlamp-admin -n headlamp
kubectl create clusterrolebinding headlamp-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=headlamp:headlamp-admin
kubectl create token headlamp-admin -n headlamp --duration=24h

The token encodes who you are and what you can do. Headlamp sends it with every API request to the Kubernetes API server. The API server validates the token and enforces RBAC rules.

Why this matters

With a no-auth dashboard like YAKD, anyone who can reach the dashboard URL has full access. In a local Minikube cluster, that is just you. On a shared cluster where the dashboard is exposed via an Ingress or NodePort, that is anyone on the network.

Token-based auth lets you control access per user. You can create different ServiceAccounts with different roles:

A developer gets a token scoped to their namespace with read/write on deployments and pods
A manager gets a read-only token across all namespaces
An SRE gets cluster-admin for troubleshooting

Each person logs in with their own token and sees only what their RBAC rules allow. Headlamp does not implement its own authorization. It delegates everything to Kubernetes RBAC, which means your existing roles and bindings work without modification.

The Plugin Architecture

Headlamp supports plugins that extend its UI. This is unusual for Kubernetes dashboards.

Plugins are JavaScript modules that register new views, modify existing ones, or add sidebar items. They run in the browser alongside the core Headlamp frontend.

Practical examples of what plugins can do:

Add a custom view showing cost data from a cloud provider
Display compliance status from a policy engine like Kyverno or OPA
Show application-specific metrics pulled from Prometheus
Add links to related documentation or runbooks

The plugin system uses a defined API. You write a React component, register it with Headlamp’s plugin registry, and it appears in the UI. The core Headlamp team maintains the plugin interface, so your extensions survive version upgrades.

For learning labs, plugins are not critical. For a team rolling out Headlamp as their standard dashboard, plugins are the difference between a generic tool and one that fits your workflow.

Multi-Cluster Support

Headlamp can connect to multiple Kubernetes clusters from a single interface. You configure additional clusters through its settings, and the UI lets you switch between them.

This matters in real environments where teams run separate clusters for development, staging, and production. Instead of switching kubectl contexts and opening separate dashboard instances, you browse all clusters from one place.

Each cluster connection uses its own authentication. You can have a cluster-admin token for your dev cluster and a read-only token for production. The permissions are enforced per cluster, per token.

YAKD and the official Kubernetes Dashboard are single-cluster tools by default. You would need to deploy a separate instance for each cluster. Headlamp removes that overhead.

When Headlamp Is the Right Choice

Headlamp fits best in team environments where access control matters.

Choose Headlamp when:

Multiple people need dashboard access with different permission levels
You want RBAC-aware access without building a custom auth layer
You need multi-cluster visibility from one UI
You want to extend the dashboard with plugins for your specific workflows
You are looking for a CNCF-backed project with active development

Choose YAKD instead when:

You are working alone on a local cluster
You want zero-config, instant access
Read-only is all you need
You do not want to deal with token generation

Choose kubectl instead when:

You need to script or automate operations
You want the fastest path to a specific piece of information
You are debugging and need to combine multiple commands with pipes and filters

Comparison Table

Feature	Headlamp	YAKD	Official Dashboard
Authentication	Token-based, RBAC-aware	None	Token or kubeconfig
Write access	Yes	No (read-only)	Yes
Plugins	Yes	No	Limited
Multi-cluster	Yes	No	No (single instance)
Exec into pods	Yes	No	Yes
CNCF project	Yes (Sandbox)	No	Yes (archived/maintained by SIG)
Install method	Helm chart	Plain manifests	Helm or manifests
Resource overhead	Moderate	Light	Moderate

The Security Model

Headlamp’s security is only as strong as the tokens you create. A few things to keep in mind.

Token duration matters. The --duration=24h flag in the lab creates a token that expires in 24 hours. In a shared environment, shorter durations reduce the window of exposure if a token leaks. Consider using OIDC integration for production setups instead of long-lived tokens.

ClusterRoleBindings are cluster-wide. The lab uses cluster-admin for convenience. In a real environment, bind ServiceAccounts to the minimum role they need. A developer who only works in the frontend namespace should get a RoleBinding scoped to that namespace, not a ClusterRoleBinding.

Network exposure matters. Port-forwarding keeps Headlamp accessible only from your machine. If you expose it via an Ingress, add TLS and consider an authentication proxy (like OAuth2 Proxy) in front of it.

The combination of RBAC-aware tokens, plugin extensibility, and multi-cluster support makes Headlamp the most capable open-source dashboard option. It requires more setup than YAKD, but that setup is the security model. The login screen is not an inconvenience. It is the feature.