Kubernetes Dashboard has been a pillar of the Kubernetes world, helping teams both build and learn. It offered a way to see what was running, check a pod, and feel less lost. Now that Dashboard is archived, many teams are asking the same question:

What is the replacement, and how can the move happen without breaking workflows?

This guide walks through that move. It keeps the steps clear, but it also explains why each step matters. By the end, you'll have a working Headlamp setup and a clean exit from Dashboard.

1. Before You Start: Know What Is Changing​

Kubernetes Dashboard and Headlamp both show what is running in a cluster, but they work differently.

• When Headlamp runs on the desktop, it uses your existing kubeconfig to connect to one or more clusters and can be extended with plugins.
• When Headlamp runs inside a cluster, it uses a Kubernetes ServiceAccount to access the API and follow RBAC rules.
• Kubernetes Dashboard, in contrast, only runs in-cluster and always relies on ServiceAccount tokens.

Understanding these models early helps you choose the right setup and permissions.

To recap:​

• Dashboard runs inside a cluster and is usually accessed through port-forward or Ingress. It often relies on ServiceAccount tokens.
• Headlamp can run on your desktop or in-cluster.
  • On desktop, it reads your kubeconfig, like kubectl does.
  • In-cluster, it can use a ServiceAccount and follow RBAC like any other workload.

1.1 How Kubernetes Dashboard Works​

Dashboard is a web app that runs inside your cluster.

• It is installed in the cluster, often with Helm.
• A single Dashboard is typically run per cluster.
• Access is usually through kubectl port-forward or an Ingress.
• Login is done with a Bearer token, often from a ServiceAccount.
• It includes forms that help create resources.
• It leans on tables and lists for navigation.

1.2 How Headlamp Works​

Headlamp acts more like a Kubernetes client with a UI.

• It can run on your desktop or in a cluster.
• It reads your kubeconfig, like kubectl does.
• It can show more than one cluster in one place.
• It favors YAML when creating or changing resources.
• It includes list views and a visual map.
• Features can be added with plugins.

1.3 What Stays the Same​

Many workflows will feel familiar:

• Browse workloads and resources
• Filter by namespace
• Inspect YAML, events, and status
• View logs
• Take actions your RBAC allows

1.4 What Changes​

A few things will feel different:

• Login shifts from pasted tokens to kubeconfig (and sometimes SSO).
• Creation shifts from forms to "apply YAML."
• Multi-cluster becomes the norm, not a special case.
• The map view shows how resources connect.

2. Pre-Migration Checklist​

This checklist is here to make the switch steady and predictable. It helps you catch the small surprises that slow teams down, like the wrong cluster context or missing permissions. It also keeps your security model intact. Headlamp should rely on the same identity and RBAC you already trust in Kubernetes. Once that is in place, you can move faster in a UI that is straightforward to navigate and works well as your clusters and workloads grow.

By the end of this section, you will have a way to prove the migration worked before turning off Dashboard.

2.1 Write Down What You Use Today​

List the basics:

• Which clusters you use (dev, staging, prod)
• Which namespaces you touch most
• What you do most often (view, edit, scale, delete, debug)
• How you access Dashboard today (port-forward or Ingress)
• How you log in (ServiceAccount token, and which RBAC bindings)

This is your baseline.

2.2 Check That kubeconfig Works​

Headlamp relies on kubeconfig, especially on desktop. Confirm your kubeconfig works before installing anything.

kubectl config current-context

Then try:

kubectl get nodes

If nodes cannot be listed, test in a namespace you can access:

kubectl get pods -n <namespace>

If these work, Headlamp can use the same identity and RBAC.

2.3 Pick a Rollout Plan​

There is no need to rush. Most teams choose one of these:

Parallel rollout (recommended)​

• Install Headlamp.
• Let people try it.
• Keep Dashboard for a short time.
• Remove Dashboard after the team is ready.

Cutover​

• Install Headlamp.
• Switch docs and links.
• Remove Dashboard soon after.

Parallel rollout is safer for shared clusters.

2.4 Decide Where Headlamp Will Run​

Either option works. Many teams use both.

Desktop​

• Relies on your kubeconfig
• Consumes no cluster resources
• No port-forward needed
• Multi-cluster works out of the box

In-cluster​

• Works well for shared, browser access
• Can be managed like other cluster apps
• Often paired with Ingress and SSO

2.5 Note Optional Dependencies​

These are common. They can be handled later.

• metrics-server (for CPU and memory graphs)
• Ingress (for an in-cluster URL)
• OIDC / SSO (for browser sign-in)
• Cleanup of old Dashboard ServiceAccounts and RBAC

3. Choose Where Headlamp Will Run (Desktop or In-Cluster)​

Headlamp offers two different methods of getting started. It can run on your desktop or inside a cluster — there is no rigid way to use it. The best choice depends on what you need day to day. For the quickest startup with the least setup, desktop is usually the most direct path. For a shared URL that a platform team can manage, running in-cluster is often the better fit.

This section helps you pick the option that matches your team, your access model, and how you want to operate going forward.

Option A: Desktop (User-Managed)​

Desktop Headlamp runs on each user's machine. It reads the same kubeconfig you use with kubectl. This keeps access tied to each user's identity and RBAC.

Why teams pick it​

• No in-cluster service to deploy or expose.
• It consumes no cluster CPU or memory.
• It relies on your kubeconfig and RBAC.
• It works with many clusters in one app.
• No port-forward is needed for day-to-day use.

Option B: In-Cluster (Best for Shared Access)​

In-cluster Headlamp is installed as a Kubernetes workload (often via Helm). This lets cluster admins manage it like other in-cluster apps.

• Cluster admins manage install, upgrades, and configuration through the Helm chart and standard Kubernetes tooling.
• Admins control Ingress and can set up OIDC login for shared access.
• It supports shared use in team environments.

4. Install Headlamp (Desktop and In-Cluster)​

The goal here is to create a Headlamp setup that fits your workflow. Desktop will be up and running quickly because Headlamp uses your local kubeconfig and does not add anything to the cluster. In-cluster install runs like any other Kubernetes workload, so it can be managed, secured, and shared. Either way, you are setting up a UI that respects the same RBAC rules you already rely on.

By the end of this section, you should be able to open Headlamp and confirm that the same clusters and namespaces you use today are visible.

4.1 Desktop Install (Fastest Way to Start)​

Install Headlamp on your machine. Then open it like any other app. Headlamp reads your kubeconfig and uses the same identity and RBAC rules as kubectl.

Windows​

Install with WinGet:

winget install headlamp

Or with Chocolatey:

choco install headlamp

macOS​

Install with Homebrew:

brew install --cask headlamp

Linux​

Install with Flatpak (Flathub):

flatpak install flathub io.kinvolk.Headlamp

Quick check​

1. Launch Headlamp.
2. Confirm a cluster context is visible.
3. Open a namespace you can access and confirm workloads are listed. Headlamp will only show actions your RBAC allows.

4.2 In-Cluster Install (Shared Access)​

Use this path for a shared UI that the platform team can manage. Headlamp supports in-cluster deployment with Helm or a YAML manifest.

Install with Helm​

Add the repo and update:

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

Create a namespace (example):

kubectl create namespace headlamp

Install the chart:

helm install headlamp headlamp/headlamp --namespace headlamp

Install with a YAML manifest (optional)​

Headlamp also provides a YAML manifest that can be applied and then adjusted to fit your needs. See the canonical instructions in Installing Headlamp in a cluster — Using simple YAML.

Check the install​

Confirm the pod is running:

kubectl get pods -n headlamp

Confirm the service exists:

kubectl get svc -n headlamp

Access it (two common ways)​

Quick test with port-forward. This is the fastest way to verify the service works:

kubectl port-forward -n headlamp svc/headlamp 8080:80

Then open: http://localhost:8080

Shared access with Ingress. For a stable URL, expose the service through your Ingress controller. The exact Ingress YAML depends on your setup. Headlamp's OIDC callback URL is your public URL plus /oidc-callback, so Ingress and TLS settings matter.

4.3 Updating Headlamp​

Updates depend on how Headlamp was installed. Package managers upgrade in place. DMG or EXE installs update by reinstalling the newer download.

macOS​

If installed with Homebrew, run:

brew upgrade headlamp

If installed from a DMG, download the newest DMG and drag Headlamp into /Applications, replacing the old version. DMG installs do not auto-upgrade.

Windows​

If installed with WinGet, run:

winget upgrade headlamp

If installed with Chocolatey, run:

choco upgrade headlamp

If installed from the EXE, download the newest installer and run it again. EXE installs do not auto-upgrade.

Linux​

If installed with Flatpak, run:

flatpak update io.kinvolk.Headlamp

If installed with AppImage, download the newest AppImage and run that file instead.

If installed with a tarball, download the newest tarball, extract it, and run the new headlamp binary.

4.4 Notes for In-Cluster Access (Keep It Safe)​

Treat an in-cluster UI like any other cluster-facing service. Use TLS, lock down who can reach it, and rely on Kubernetes auth and RBAC to control what users can do.

5. Authentication and RBAC​

A new UI should not mean a new security model. Headlamp does not decide what a user can do — Kubernetes does. Headlamp reflects the same authentication and RBAC rules your cluster already enforces.

In this section, you will line up how people sign in and confirm that permissions behave as expected. When you finish, users should see only what they are allowed to see, and they should be able to do only what they are allowed to do.

This section covers two setups: desktop and in-cluster.

5.1 Desktop: Use kubeconfig​

On desktop, Headlamp reads your kubeconfig and uses the same credentials you use with kubectl. There is no separate token login flow to manage.

Step 1: Confirm your kubeconfig works​

kubectl config current-context

Then test access:

kubectl get nodes

If nodes cannot be listed, test a namespace you can access:

kubectl get pods -n <namespace>

If these commands work, your kubeconfig and credentials are valid for Headlamp too.

Step 2: Point Headlamp at the right kubeconfig (if needed)​

Headlamp can use the default kubeconfig path. It can also use a custom file path. Set KUBECONFIG to choose a specific file.

Example:

KUBECONFIG=/path/to/config headlamp

More than one kubeconfig file can be loaded at once. On Unix systems, separate paths with :. On Windows, separate paths with ;.

What to expect in the UI​

Headlamp adapts to your RBAC permissions. If permission to edit or delete a resource is missing, Headlamp will not offer those actions.

5.2 In-Cluster: Shared Access Needs a Sign-In Plan​

In-cluster Headlamp is shared by many users. A clear plan for sign-in and access is required. Headlamp supports OpenID Connect (OIDC) for a "Sign in" flow.

Most teams choose one of these patterns:

• A. Configure Headlamp with OIDC (built-in).
• B. Put an auth layer in front of Headlamp (common in enterprises).

A. Built-In OIDC (Headlamp)​

To use OIDC, Headlamp needs:

• Client ID
• Client secret
• Issuer URL
• (Optional) scopes

The OIDC provider must also allow Headlamp's callback URL. The callback is your Headlamp URL plus /oidc-callback.

Example: https://headlamp.example.com/oidc-callback

Ingress note: if Headlamp is behind an Ingress or load balancer, make sure it forwards X-Forwarded-Proto. If it does not, Headlamp may generate an http callback URL instead of https, which can break login.

B. Auth Layer in Front of Headlamp​

Some teams protect Headlamp with an identity-aware proxy or a platform auth system. This keeps sign-in consistent across tools.

Headlamp docs include an example using OpenUnison, which can deploy Headlamp with hardened defaults and integrate with identity providers.

5.3 RBAC: Keep It Least-Privilege​

Kubernetes security starts with API authentication and authorization (RBAC). Headlamp respects those rules.

Practical guidance​

• Start with the lowest permissions that still let users do their job.
• If Dashboard used a high-privilege ServiceAccount token, plan to remove or tighten that access after the move.
• For in-cluster, treat the UI like any other endpoint. Use TLS and limit network access.

5.4 Quick Troubleshooting​

Desktop: "Cluster is not visible"​

The kubeconfig may not be in the default location. Point Headlamp to the file with KUBECONFIG or a file path.

In-cluster: "OIDC login fails after redirect"​

Confirm the provider allows https://YOUR_URL/oidc-callback. If Ingress is in use, make sure it forwards X-Forwarded-Proto.

6. Manage Multiple Clusters​

This is one of the biggest practical shifts from Kubernetes Dashboard. Dashboard is typically visited one cluster at a time. Headlamp is built for the way teams work now, where dev, staging, and prod live side by side. Instead of juggling tabs or switching tools, one UI stays open and clusters change as the work moves.

The key idea: if kubectl can reach a cluster, Headlamp can usually reach it too. This section shows how Headlamp finds your clusters and how to move between them without losing your place.

Clusters Come From Your kubeconfig​

Headlamp reads clusters from your kubeconfig files. That means the clusters reachable with kubectl can also show up in Headlamp.

Switch Clusters in the UI​

Once Headlamp loads your kubeconfig, the cluster selector switches between clusters. This reduces friction when moving between dev, staging, and prod.

Optional: Use More Than One kubeconfig File​

If you keep separate kubeconfig files, they can be loaded together. Headlamp supports multiple kubeconfig paths in KUBECONFIG.

Unix/macOS/Linux (: separator):

KUBECONFIG=~/.kube/dev:~/.kube/prod headlamp

Windows (; separator):

$env:KUBECONFIG="$HOME\.kube\dev;$HOME\.kube\prod"

Optional: Add a Cluster From Inside Headlamp​

Clusters can also be added by loading additional kubeconfig files from the UI.

Permissions Stay the Same​

Multi-cluster does not change security rules. Each cluster still enforces its own RBAC. Headlamp shows only what your identity can do in the selected cluster.

7. Navigate and Understand Resources​

This is where things should start to feel familiar again. For anyone who used Kubernetes Dashboard, the core resource views in Headlamp will be recognizable right away. Pods, deployments, services, and namespaces are all still here. What changes is how quickly you can move between them and understand how they connect.

This section walks through the layout, shows where to find what you need, and introduces a few tools that help build context faster when something goes wrong.

Find Resources in Familiar Places​

Headlamp groups resources in a way that maps closely to Dashboard:

• Workloads for Pods, Deployments, StatefulSets, and Jobs
• Network for Services and Ingress
• Storage for PersistentVolumes and Claims
• Configuration for ConfigMaps and Secrets
• Nodes for cluster infrastructure

Namespace filtering is at the top of the UI, the same place as in Dashboard.

Inspect and Edit Resources​

From any list, clicking into a resource shows the details:

• Status and conditions
• Events
• Labels and annotations
• The full YAML definition

If RBAC allows it, YAML can be edited directly from the UI. If it does not, Headlamp shows the resource as read-only. This matches how kubectl behaves.

Use Search and Filters to Move Faster​

Headlamp adds faster search and filtering across lists. This helps when clusters or namespaces get large. Views can be narrowed without jumping between pages.

Understand Relationships With Map View​

Dashboard mostly shows resources as lists. Headlamp also includes a Map View.

View of resource relationships in Headlamp Map View shows how resources relate to each other:

• Deployments
• ReplicaSets
• Pods
• Services

This helps during troubleshooting. Instead of clicking through several pages, the connections are visible at once. Missing links or broken relationships are faster to spot.

When to Use Lists vs Map View​

• Use lists when the target resource is already known.
• Use Map View when the goal is to understand why something is not working.

Both views work on the same data. The choice is about how much context you want at that moment.

8. Deploy Applications With YAML​

For many Kubernetes Dashboard users, this is where the differences between Dashboard and Headlamp become noticeable. Dashboard guided users with forms. Headlamp leans into manifests. That shift is not about making things harder — it is about making what gets deployed clearer and more repeatable. When YAML is applied, the cluster receives exactly what is on the page, and the same manifest can be reused in Git, CI, or any other workflow.

This section shows how to deploy with YAML in Headlamp and how to keep the process manageable for anyone used to a wizard.

From Forms to Manifests​

In Kubernetes Dashboard, applications were often deployed by filling in a form:

• Container image
• Replicas
• Service type

Headlamp does not include the same wizard. Instead, YAML is applied directly from the UI.

This matches how most teams deploy today:

• Manifests live in Git.
• CI/CD applies them.
• Helm or GitOps tools manage changes.

Headlamp fits into that flow rather than replacing it.

Create Resources Using YAML​

To deploy an application in Headlamp:

1. Select a cluster and namespace.
2. Click Create.
3. Paste or upload a YAML manifest.
4. Review it.
5. Click Apply.

The resource appears immediately in the UI. If the manifest is not valid, Headlamp shows the same errors the Kubernetes API would return.

Generate YAML Quickly​

If the Dashboard wizard is missed, YAML can still be generated quickly. For example:

kubectl create deployment nginx \
  --image=nginx \
  --dry-run=client \
  -o yaml > nginx.yaml

Edit the file if needed, then paste it into Headlamp and apply it. This produces a repeatable manifest instead of an object created only through a UI.

What About Helm or GitOps?​

Both work well with Headlamp.

• Install with Helm as usual.
• Deploy with GitOps pipelines as usual.
• Use Headlamp to view, inspect, and debug what is running.

Headlamp does not replace those tools. It provides visibility into what they create.

What to Expect Compared to Dashboard​

• No multi-step deploy form.
• More direct work with YAML.
• Clearer visibility into what is actually applied to the cluster.
• The same manifest can be reused in CI, Git, or other tools.

9. Deploy and Debug Workloads​

Day-to-day debugging is a key area for both Kubernetes UIs. For anyone who used Kubernetes Dashboard, it was the place to open logs, check events, and figure out why something was failing. Headlamp supports those same workflows and reduces a few common friction points along the way.

This section walks through the core debugging loop in Headlamp — from logs and exec to metrics and events — so troubleshooting can happen without leaving the UI.

View Logs​

Pod logs can be viewed directly in the UI.

To check logs:

1. Open Workloads.
2. Select Pods.
3. Click a pod.
4. Open the Logs tab.

If the pod has more than one container, the view can switch between containers. Logs stream live, which helps during rollouts or active incidents.

Exec Into Running Pods​

Headlamp also opens a shell inside a container.

From a pod view:

• Open the pod actions menu.
• Choose Terminal or Exec.

This opens an interactive session inside the container. It replaces the need to switch back to the terminal for quick checks.

This action follows RBAC rules. If kubectl exec is not permitted, Headlamp will not allow it either.

Check Metrics and Resource Usage​

Headlamp can show CPU and memory usage for Pods and Nodes. This works the same way it did in Dashboard.

A few things to know:

• Metrics require metrics-server to be installed in the cluster.
• If metrics are missing, Headlamp shows a clear notice.
• Once metrics are available, usage appears on pod and node views.

This makes it straightforward to answer questions like:

• Is this pod using too much memory?
• Is a node under pressure?

View Events When Something Goes Wrong​

Events are often the fastest way to understand failures. In Headlamp:

• Events are visible on resource detail pages.
• Warnings and errors are tied to Pods, Nodes, or Deployments.

This is often the first place to look when a workload is stuck or crashes.

How This Compares to Dashboard​

What stays the same​

• Log viewing
• Event inspection
• RBAC-aware actions

What improves​

• Built-in exec sessions
• Clearer layout and filtering
• Fewer context switches between UI and CLI

10. Remove Kubernetes Dashboard​

This is the last step, and it should feel routine. Kubernetes functionality is not being removed — an old access path and an extra moving part are. The goal is to reduce the surface area of your environment once Headlamp is proven and the team is comfortable.

This section confirms the common workflows still work, then walks through uninstalling Dashboard and cleaning up any leftover ServiceAccounts or RBAC that were only there to support it.

Removing Dashboard reduces clutter and avoids keeping unused access paths around.

Confirm Headlamp Covers Your Needs​

Before uninstalling anything, confirm:

• Users can access the clusters they need in Headlamp.
• Common tasks work:
  • Browse resources
  • Deploy with YAML
  • View logs and events
  • Exec into Pods (if allowed)
• RBAC behaves as expected for different roles.

Once these checks pass, Dashboard is ready to be removed.

Uninstall the Dashboard​

If Kubernetes Dashboard was installed with Helm, remove it with:

helm uninstall kubernetes-dashboard -n kubernetes-dashboard

If Dashboard was installed by a manifest or add-on, remove it using the same method that installed it.

After removal, confirm the resources are gone:

kubectl get pods -n kubernetes-dashboard

Clean Up Access Artifacts (Recommended)​

Many Dashboard setups used dedicated ServiceAccounts and cluster-wide roles.

Review and remove anything that was created only for Dashboard access, such as:

• ServiceAccounts
• Role bindings or cluster role bindings
• Old documentation that points users to Dashboard URLs or port-forward commands

This reduces long-lived credentials and unused permissions.

Communicate the Change​

Make sure the team knows:

• Headlamp is now the primary Kubernetes UI.
• How to access it (desktop or URL).
• Where to go for help if something feels different.

11. Post-Migration Checklist​

The checklist below covers the basics that matter most: access, RBAC, and the tasks people do every day. It also confirms cleanup is real and not assumed.

Access and visibility​

• Headlamp opens without errors.
• Users can access the correct clusters.
• Namespace filtering works as expected.
• Multi-cluster switching behaves correctly.

Authentication and RBAC​

• Desktop users access clusters using kubeconfig.
• In-cluster users can sign in using the chosen auth method.
• Users only see actions their RBAC allows.
• No unexpected permission errors appear during normal use.

Core workflows​

• Resources load under Workloads, Network, and Configuration.
• YAML can be viewed and edited where permissions allow.
• Applications can be deployed using Create and YAML.
• Logs load correctly for running Pods.
• Exec works for users who are allowed to use it.
• Metrics appear if metrics-server is installed.

Operational confidence​

• Teams can troubleshoot without switching tools.
• Map View helps explain relationships during debugging.
• Platform or DevOps teams know how Headlamp is installed and managed.

Cleanup confirmation​

• Kubernetes Dashboard is no longer running.
• Dashboard-only ServiceAccounts and RBAC bindings are removed.
• Internal docs no longer reference Dashboard URLs or port-forward commands.

Team alignment​

• The team knows Headlamp is the default Kubernetes UI.
• Onboarding docs point new users to Headlamp.
• There is a clear path for feedback or questions.

The move from Kubernetes Dashboard to Headlamp is complete. Your team can rely on the same Kubernetes access model, work across clusters, and follow workflows that match how Kubernetes is already used. From here, Headlamp becomes the default UI, whether on the desktop or in shared environments. As needs grow, it can stay as-is or be extended with plugins and new views over time.

To help shape what comes next, join the Headlamp community and contribute at headlamp.dev.

This is the gap Headlamp fills with HolmesGPT by centralizing data and context to get answers in a familiar environment.

The Real Problem Is Not Missing Data​

Most Kubernetes teams are not short on data. Modern clusters generate a steady stream of signals about what is happening across the system. On paper, everything needed to diagnose an issue already exists.

The real problem is making sense of it.

Understanding why a rollout is stuck or a pod keeps restarting takes context and time. Humans do this by testing one idea at a time. We gather signals, form a hypothesis, then move to the next. Holmes can do this work in parallel. It looks across related resources and controller behavior at once, finding answers faster than a single person can.

Kubernetes problems end up feeling harder than they should be with multiple layers of friction.

What HolmesGPT Brings to Kubernetes​

HolmesGPT is designed to reason about Kubernetes behavior, not just report state. It looks at real cluster signals together, including logs, events, and resources. It understands how failures propagate and how controller logic affects outcomes.

Instead of listing symptoms, HolmesGPT focuses on causes. Instead of showing raw output, it explains what is happening and how to fix it. This shifts troubleshooting from guesswork to understanding.

Why Headlamp Is the Right Place for HolmesGPT​

Headlamp is where Kubernetes work already happens. It is where teams explore clusters, inspect workloads, and notice when something looks wrong. This is exactly the place where signals need to be turned into answers. Many teams try to close this gap by adding more tools. Another dashboard. Another alerting system. Another surface to check during an incident. Each one adds value, but each one also adds friction.

The HolmesGPT integration takes a different approach. Instead of adding another tool, it brings reasoning into an existing workflow. Headlamp does not become something new to learn. It becomes easier to use because it builds on an environment teams already know. When insight lives in the same place as management, it gets used. Context stays intact. Teams move more quickly from questions to action.

Watch the demo:

From Signals to Understanding​

Troubleshooting in Headlamp feels different because the explanation lives in the same place as the investigation. HolmesGPT works in context, alongside the workloads, namespaces, and controllers you are already viewing. It explains how the resources on screen relate to each other, without sending you to another tool.

Traditional observability shows what is happening, but it rarely explains why. A pod restart loop might come from a bad configuration, a missing secret, or a failure elsewhere in the system. Logs alone cannot tell you which one matters. Events add clues, but they still only show part of the story.

That context is what changes the troubleshooting experience. Patterns that are hard to spot in raw output become clear when they are tied directly to Kubernetes objects. Instead of stitching clues together across tools, teams see explanations next to the problem they are trying to understand.

Insight That Fits How Teams Work​

Kubernetes is rarely owned by one role. Developers focus on application behavior. Operators focus on stability. Platform teams look for patterns and consistency across clusters. HolmesGPT helps create a shared understanding across those roles. The same explanation can help a developer understand why a rollout failed and help an operator confirm a broader issue. The language is clear, the context is shared, and the insight is grounded in real cluster state.

Just as important, this insight fits into existing workflows. Teams do not need to change how they work or learn a new system. When understanding appears at the right moment and in the same place as investigation, it gets used. This reduces handoffs, avoids miscommunication, and helps teams move from discussion to action faster.

Clear Answers When They Matter Most​

HolmesGPT in Headlamp turns scattered signals into clear explanations, right where you already investigate. You keep context, move faster, and make decisions with more confidence.

If you want to try it, open Headlamp, enable the AI Assistant, and connect HolmesGPT. To add the Holmes agent to your cluster, follow the setup instructions. The next time an alert fires, you can go from signals to answers without leaving the UI.

Kubernetes teams lose time switching between tools to understand what is happening in their clusters. Many tools offer deep insight, but that expertise often lives outside the UI where teams actually work. This breaks context and slows decisions. MCPs bring powerful expertise into Kubernetes workflows. They can explain how systems behave at runtime, how workloads interact, and where issues begin. But today, that expertise is usually accessed through separate tools or commands.

The challenge is not the MCPs themselves. It is where they live.

Teams move between dashboards, terminals, and scripts to get answers. They learn something in one place, then act somewhere else. Context gets lost along the way. Kubernetes is where applications run and where decisions are made. MCP expertise should live there too. In context. Next to the workloads and applications it describes.

The Solution​

Headlamp brings MCP expertise directly into the Kubernetes UI.

With MCP support, Headlamp makes specialized insight available where Kubernetes work already happens. Instead of accessing MCPs through separate tools, teams use them in context alongside their workloads. This reduces context switching, but it also does more than that. MCPs bring focused expertise into the UI. MCPs interpret the domains, behaviors, and systems they surface. Helping users to understand in a way that matches the Kubernetes resources on screen.

The workflow stays simple. You look at an application. You use an MCP to understand what is happening. You act without leaving Headlamp. By unifying MCP expertise inside the Kubernetes UI, Headlamp turns insight into something teams can use right away. Not something teams have to translate or chase down.

What MCP Support Means in Headlamp​

MCP support in Headlamp reduces context switching by making MCPs part of the Kubernetes workflow. MCPs are built in, not bolted on.

MCPs are available inside the same UI teams use to explore clusters, inspect workloads, and troubleshoot issues. Instead of switching tools, you interact with MCPs alongside Kubernetes resources. Their output appears next to the workloads and applications it describes, where it is easiest to understand. This does more than simplify access. MCPs bring focused expertise into the UI. They surface insight that shows how systems behave, components interact, and where problems start. That understanding is tied directly to Kubernetes context, not shown in isolation.

By treating MCPs as first‑class integrations, Headlamp keeps workflows simple. Kubernetes resources, application views, and MCP expertise live in one place. Teams spend less time stitching tools together and more time understanding what is happening.

Why This Matters for Kubernetes Teams​

Kubernetes is rarely managed by one role. Developers, operators, and platform engineers all work in the same clusters. However, they look at those clusters for different signals and ask different questions.

MCPs in Headlamp bring that expertise closer to the work.

Developers gain clearer insight into how their applications behave at runtime. MCPs help explain what is happening inside workloads, not just that something failed. This makes issues easier to understand and faster to fix.

Platform engineers benefit from consistency and control. MCP expertise shows up inside a familiar UI and follows existing Kubernetes permissions. Teams gain deeper operational understanding without adding another system to manage.

Operators see focused insight where investigations already happen. MCP output appears in the chat box alongside logs, events, and resource state, making it easier to connect signals and identify root causes.

By unifying MCP expertise inside the Kubernetes UI, Headlamp creates a shared understanding of the cluster. Teams spend less time translating between tools and more time solving problems together.

MCPs in an Application‑Centric World​

Headlamp helps teams think in terms of applications, not just individual Kubernetes resources. Projects group related workloads, services, and configurations into a single, scoped view.

MCP support enhances projects by bringing specialized insight into the same application context.

Instead of running MCPs across an entire cluster and sorting through results later, MCPs can be used where the application lives. Their expertise is applied to the namespaces, workloads, and resources that matter, not buried in cluster‑wide noise.

This makes MCP insight easier to understand and easier to trust. Teams see expert signals in the context of the application they are working on. The result is less distraction and more focus on what actually affects the app.

Setting Up MCP Support​

The Model Context Protocol (MCP) is an open standard that lets the Headlamp AI Assistant talk to external tools through a unified interface—think of it as a plugin system for your AI. Connect an MCP server (like the Flux operator) and its capabilities appear alongside Headlamp's built-in Kubernetes tooling, ready to use in chat.

How it works​

The Headlamp desktop app spawns MCP servers as local processes, discovers the tools they expose, and hands them to the LLM. When you ask a question that needs an external tool, the assistant picks the right one, runs it, and formats the results into tables, metrics, or plain text.

Setting it up​

1. Open the AI Assistant plugin settings and navigate to the MCP Servers section.
2. Turn Enable MCP servers on.

3. Click Add Server, then enter a name, the server command, and any args or environment variables it needs.

Example:

• Name — A unique identifier for the server.
• Command — The executable to run (e.g., flux-operator-mcp).
• Args — Command-line arguments (e.g., serve --kube-context HEADLAMP_CURRENT_CLUSTER).
• Environment Variables — Optional env vars required by the server (e.g., KUBECONFIG).

4. Save. Headlamp will spawn the process and discover its tools. Review and toggle individual tools under the MCP Tool Settings tab.

After that, just ask a question. For example, "List all Flux HelmReleases in the default namespace"—and the assistant takes care of the rest.

A few things worth noting: MCP is desktop-only (Electron), you need at least one AI provider configured, and you can run multiple servers side by side. Tool approval settings let you gate write operations before they execute.

Use Cases That Fit Well​

MCP support in Headlamp works best when teams need expert insight in context.

Some MCPs focus on how applications behave at runtime. For example, the Inspektor Gadget MCP can surface low‑level signals from running workloads. When used in Headlamp, those signals are tied directly to pods and namespaces. Teams see how an application behaves while it is running, not just that something is wrong.

Other MCPs focus on how applications are delivered and kept in sync. The Flux MCP brings insight into deployment state, drift, and reconciliation. Instead of checking a separate system, teams can understand why a workload looks the way it does right from the Kubernetes UI.

In both cases, the value is not just access to data. It is access to expertise. MCPs explain what is happening and why, in the context of the application teams are already working on. By keeping that expertise inside Headlamp, teams spend less time chasing answers across tools and more time acting on what they learn.

Conclusion​

MCPs bring more than raw signals. They bring expertise. They understand how systems behave, how applications are delivered, and where problems begin.

Headlamp brings that expertise into the Kubernetes UI. MCP insights show up where teams already work, tied to real workloads and applications. Context stays intact. Decisions get easier. Action follows faster.

This is about more than reducing context switching. It is about giving Kubernetes teams smarter operational intelligence. Intelligence grounded in the domain knowledge MCPs provide and delivered in a way that fits how teams actually work.

This is also part of a longer journey. We are building Headlamp toward a Unified Kubernetes Workspace. One place where ease of use, context, insight, and action come together, so Kubernetes feels connected instead of fragmented.

Talks​

This year we have Headlamp-related talks from both core members of the project, and from the wider community.

Title: Leveling up with Radius: Custom Resources and Headlamp Integration for Real-World Workloads
Speakers: Nuno Guedes (Millennium BCP) and Will Tsai (Microsoft)
Date and time: Tuesday, March 24, 3:15 PM - 3:45 PM CET
Room: Forum
Description: Learn how Millennium bcp extended the Radius framework for production workloads with complex dependencies (Datadog monitors, AI models, internal APIs) and built a Headlamp plugin that visualizes the app graph and maps dependencies across cloud platforms.

Title: How To (Not) Fork Headlamp
Speaker: Joaquim Rocha (Amutable)
Date and time: Thursday, March 26, 11:45 AM - 12:15 PM CET
Room: E106-108
Description: Should you write a plugin or fork the whole project? This talk walks through Headlamp's architecture and plugin system, covers the trade-offs, and shares practical advice for keeping your customizations maintainable either way.

Title: Ping SRE? I Am the SRE! Awesome Fun I Had Drawing a Zine for Troubleshooting Kubernetes Deployments
Speaker: Rene Dudfield (Microsoft)
Date and time: Wednesday, March 25, 4:45 PM - 5:15 PM CET
Room: Hall 7, Room A
Description: Patterns from troubleshooting Kubernetes issues in the Headlamp community turned into a hand-drawn mini zine for diagnosing deployment problems. Come see how a notebook full of doodles became a 16-page troubleshooting guide, and maybe get inspired to draw your own.

Title: Headlamp: Build Kubernetes Experiences Your Way! (ContribFest)
Speakers: Joaquim Rocha (Amutable) and Santhosh Nagaraj (Microsoft)
Date and time: Wednesday, March 25, 11:00 AM - 12:15 PM CET
Room: G107
Description: A hands-on workshop where you'll build a Headlamp plugin with guidance from the maintainers. Whether you're just getting started or already have contributions in flight, this is a great chance to dig in. Bring your laptop!

Co-located: Maintainer Summit​

Title: Does Your Project Want a UI in kubernetes-sigs/headlamp?
Speakers: Rene Dudfield and Santhosh Nagaraj (Microsoft)
Date and time: Sunday, March 22, 11:35 AM - 12:10 PM CET
Room: Forum
Description: Headlamp already has UI plugins for projects like cert-manager, Gateway API, Karpenter, and KEDA. In this Maintainer Summit session, the team invites CNCF project maintainers to collaborate on bringing UI support to even more projects.

Project Pavilion​

Come say hi at our kiosk (P-6B) in the Project Pavilion (Solutions Showcase, Halls 1-5). We'll be there with live demos and happy to chat about anything Headlamp, on Wednesday, March 25: 10:00 AM - 1:30 PM CET.

Also at KubeCon​

Headlamp is also expected to make an appearance in a couple of other sessions:

• Sponsored Keynote: Scaling Platform Ops with AI Agents: Troubleshooting to Remediation by Jorge Palma (Microsoft) and Natan Yellin (Robusta), Tuesday, March 24 at 10:25 AM CET in Hall 12.
• Visualizing GitOps: A Tour of Flux UIs in the Open Source Ecosystem by Stefan Prodan (ControlPlane), Thursday, March 26 at 1:45 PM CET, surveying open-source UIs for Flux, Headlamp included.

See You There​

Whether it's at a talk, the ContribFest, or the Project Pavilion, we'd love to connect. See you in Amsterdam!

This isn't about launching a new process or creating an official catalog. It's simply a better way to highlight what's already out there and encourage more contributions from the community.

What You'll Find​

The new section shows plugins from the Headlamp team and the community. From UI enhancements to observability tools, these plugins show how flexible Headlamp can be.

Each plugin links to its GitHub repository so you can check out the source, try it, or contribute improvements.

Have a Plugin to Share?​

If you've built a plugin that you think others would find useful, we'd love to hear about it. Reach out to us by opening an issue in the Headlamp plugins GitHub repo, and we'll discuss adding it to the website so more people can discover your work.

Why This Matters​

Headlamp thrives on collaboration. By making plugins more visible, we hope to spark ideas, encourage contributions, and make it easier for developers to build on each other's work.

Take a Look​

Visit the new plugin section now and see what's possible. If you have an idea for a plugin or one already built, let us know. We'd love to showcase it.

Whether you caught our demos and sessions in person or are just catching up now, we wanted to give a few updates and highlight how Headlamp has evolved in 2025.

Updates​

Joining Kubernetes SIG UI​

This year marked a big milestone for the project: Headlamp is now officially part of Kubernetes SIG UI. This move brings roadmap and design discussions even closer to the core Kubernetes community and reinforces Headlamp’s role as a modern, extensible UI for the project.

As part of that, we’ve also been sharing more about making Kubernetes approachable for a wider audience, including an appearance on Enlightning with Whitney Lee and a talk at KCD New York 2025.

AKS Desktop Preview​

Now in private preview is AKS Desktop, an application-centric experience addressing the complexity developers face when working with Kubernetes. Rather than troubleshooting setup, teams can quickly create and manage applications on Azure Kubernetes Service. Built on Headlamp’s intuitive interface, AKS Desktop combines supported and preconfigured AKS features so engineers can focus on building great solutions.

Sign up here to apply for the private preview for yourself.

Linux Foundation mentorship​

This year, we were excited to work with several students through the Linux Foundation’s Mentorship program, and our mentees have already left a visible mark on Headlamp:

• Adwait Godbole built the KEDA plugin, adding a UI in Headlamp to view and manage KEDA resources like ScaledObjects and ScaledJobs.
• Dhairya Majmudar set up an OpenTelemetry-based observability stack for Headlamp, wiring up metrics, logs, and traces so the project is easier to monitor and debug.
• Aishwarya Ghatole led a UX audit of Headlamp plugins, identifying usability issues and proposing design improvements and personas for plugin users.
• Anirban Singha developed the Karpenter plugin, giving Headlamp a focused view into Karpenter autoscaling resources and decisions.
• Aditya Chaudhary improved Gateway API support, so you can see networking relationships on the resource map, as well as improved support for many of the new Gateway API resources.
• Faakhir Zahid completed a way to easily manage plugin installation with Headlamp deployed in clusters.
• Saurav Upadhyay worked on backend caching for Kubernetes API calls, reducing load on the API server and improving performance in Headlamp.

New changes​

Multi-cluster view​

Managing multiple clusters is challenging: teams often switch between tools and lose context when trying to see what runs where. Headlamp solves this by giving you a single view to compare clusters side-by-side. This makes it easier to understand workloads across environments and reduces the time spent hunting for resources.

Projects​

Kubernetes apps often span multiple namespaces and resource types, which makes troubleshooting feel like piecing together a puzzle. We’ve added Projects to give you an application-centric view that groups related resources across multiple namespaces – and even clusters. This allows you to reduce sprawl, troubleshoot faster, and collaborate without digging through YAML or cluster-wide lists.

Changes:

• New “Projects” feature for grouping namespaces into app- or team-centric projects
• Extensible Projects details view that plugins can customize with their own tabs and actions

Navigation and Activities​

Day-to-day ops in Kubernetes often means juggling logs, terminals, YAML, and dashboards across clusters. We redesigned Headlamp’s navigation to treat these as first-class “activities” you can keep open and come back to, instead of one-off views you lose as soon as you click away.

Changes:

• A new task bar/activities model lets you pin logs, exec sessions, and details as ongoing activities
• An activity overview with a “Close all” action and cluster information
• Multi-select and global filters in tables

Thanks to Jan Jansen and Aditya Chaudhary.

Search and map​

When something breaks in production, the first two questions are usually “where is it?” and “what is it connected to?” We’ve upgraded both search and the map view so you can get from a high-level symptom to the right set of objects much faster.

Changes:

• An Advanced search view that supports rich, expression-based queries over Kubernetes objects
• Improved global search that understands labels and multiple search items, and can even update your current namespace based on what you find
• EndpointSlice support in the Network section
• A richer map view that now includes Custom Resources and Gateway API objects

Thanks to Fabian, Alexander North, and Victor Marcolino from Swisscom, and also to Aditya Chaudhary.

OIDC and authentication​

We’ve put real work into making OIDC setup clearer and more resilient, especially for in-cluster deployments.

Changes:

• User information displayed in the top bar for OIDC-authenticated users
• PKCE support for more secure authentication flows, as well as hardened token refresh handling
• Improved support for public OIDC clients (e.g., AKS and EKS)
• New guide for setting up Headlamp on AKS with Microsoft Entra ID using OAuth2 Proxy

Thanks to David Dobmeier and Harsh Srivastava.

App Catalog and Helm​

We’ve broadened how you deploy and source apps via Headlamp, specifically supporting vanilla Helm repos.

Changes:

• A more capable Helm chart with optional backend TLS termination, PodDisruptionBudgets, custom pod labels, and more
• Improved formatting and added missing -oidc-use-access-token arg in the Helm chart
• New in-cluster Helm support with an --enable-helm flag and a service proxy

Thanks to Vrushali Shah and Murali Annamneni from Oracle, and also to Pat Riehecky, Joshua Akers, Rostislav Stříbrný, Rick L, and Victor.

Performance, accessibility, & UX​

Finally, we’ve spent a lot of time on the things you notice every day but don’t always make headlines: startup time, list views, log viewers, accessibility, and small network UX details. A continuous accessibility self-audit has also helped us identify key issues and make Headlamp easier for everyone to use.

Changes:

• Significant desktop improvements, with up to 60% faster app loads and much quicker dev-mode reloads for contributors
• Numerous table and log viewer refinements: persistent sort order, consistent row actions, copy-name buttons, better tooltips, and more forgiving log inputs
• Accessibility and localization improvements, including fixes for zoom-related layout issues, better color contrast, improved screen reader support, and expanded language coverage
• More control over resources, with live pod CPU/memory metrics, richer pod details, and inline editing for secrets and CRD fields
• A refreshed documentation and plugin onboarding experience, including a “Learn” section and plugin showcase
• A more complete NetworkPolicy UI and network-related polish
• Nightly builds available for early testing

Thanks to Jaehan Byun and Jan Jansen.

Plugins & Extensibility​

Discovering plugins is simpler now – no more hopping between Artifact Hub and assorted GitHub repos. Browse our dedicated Plugins page for a curated catalog of Headlamp-endorsed plugins, along with a showcase of featured plugins.

Headlamp AI Assistant​

Managing Kubernetes often means memorizing commands and juggling tools. Headlamp’s new AI Assistant changes this by adding a natural-language interface built into the UI. Now, instead of typing kubectl or digging through YAML you can ask, “Is my app healthy?” or “Show logs for this deployment,” and get answers in context, speeding up troubleshooting and smoothing onboarding for new users. Learn more about it here.

New plugins additions​

Alongside the new AI Assistant, we’ve been growing Headlamp’s plugin ecosystem so you can bring more of your workflows into a single UI, with integrations like Minikube, Karpenter, and more.

Highlights from the latest plugin releases:

• Minikube plugin, providing a locally-stored single node Minikube cluster
• Karpenter plugin, with support for Azure Node Auto-Provisioning (NAP)
• KEDA plugin, which you can learn more about here
• Community-maintained plugins for Gatekeeper and KAITO

Thanks to Vrushali Shah and Murali Annamneni from Oracle, and also to Anirban Singha, Adwait Godbole, Sertaç Özercan, Ernest Wong, and Chloe Lim.

Other plugins updates​

Alongside new additions, we’ve also spent time refining plugins that many of you already use, focusing on smoother workflows and better integration with the core UI.

Changes:

• Flux plugin: Updated for Flux v2.7, with support for newer CRDs, navigation fixes so it works smoothly on recent clusters
• App Catalog: Now supports Helm repos in addition to Artifact Hub, can run in-cluster via /serviceproxy, and shows both current and latest app versions
• Plugin Catalog: Improved card layout and accessibility, plus dependency and Storybook test updates
• Backstage plugin: Dependency and build updates, more info here

Plugin Development​

We’ve focused on making it faster and clearer to build, test, and ship Headlamp plugins, backed by improved documentation and lighter tooling.

Changes:

• New and expanded guides for plugin architecture and development, including how to publish and ship plugins
• Added i18n support documentation so plugins can be translated and localized
• Added example plugins: ui-panels, resource-charts, custom-theme, and projects
• Improved type checking for Headlamp APIs, restored Storybook support for component testing, and reduced dependencies for faster installs and fewer updates
• Documented plugin install locations, UI signifiers in Plugin Settings, and labels that differentiated shipped, UI-installed, and dev-mode plugins

Security upgrades​

We've also been investing in keeping Headlamp secure – both by tightening how authentication works and by staying on top of upstream vulnerabilities and tooling.

Updates:

• We've been keeping up with security updates, regularly updating dependencies and addressing upstream security issues.
• We tightened the Helm chart's default security context and fixed a regression that broke the plugin manager.
• We've improved OIDC security with PKCE support, helping unblock more secure and standards-compliant OIDC setups when deploying Headlamp in-cluster.

Conclusion​

Thank you to everyone who stopped by our booth, joined our sessions, or chatted with us during KubeCon + CloudNativeCon North America 2025. Seeing the different ways teams are adopting and extending the project is a big part of what keeps us moving forward.

If you’re catching up after the event, all these updates are available today. Try the latest Headlamp release, explore the new views, plugins, and docs, and share your feedback with us on Slack or GitHub – your feedback helps shape where Headlamp goes next.

Applications in Kubernetes are made up of multiple resources like pods, services, and deployments, often spread across namespaces. Without a way to group these resources, managing, troubleshooting, and collaborating can feel like piecing together a puzzle.

Headlamp Projects (since version 0.35.0) gives you a single, application-centric view. Instead of navigating cluster-wide lists or searching for labels, you can organize related resources into logical groups. This makes it easier to understand and manage your app as a whole.

Headlamp started as a UI for Kubernetes operators, focusing on resources such as pods, services, ConfigMaps, and more. It even includes a Map view to visualize relationships. For developers, though, a resource-centric approach can feel indirect. Projects bridges that gap by providing a clear, application-first experience.

Introducing Projects​

To solve this, we introduced Headlamp Projects. Projects provide a flexible way to group related Kubernetes resources into a single, scoped view. Instead of jumping between namespaces or digging through YAML, you can organize everything that makes up an application across one or more namespaces and even multiple clusters into a project. This gives teams clarity, reduces resource sprawl, and makes collaboration easier.

Projects are built on top of Kubernetes, no special custom resources are needed, so you are still working with native resources like namespaces, deployments, and services. The difference is that Headlamp adds a visual layer that brings the project related resources together in one place, lowering the barrier to entry and making it easier for teams to manage applications without getting lost in cluster-wide complexity.

Solving the Onboarding Bottleneck with Headlamp Projects​

Headlamp Projects change that by giving teams a scoped, visual environment that lowers the barrier to entry. Instead of YAML files and manual RBAC configuration, a Dev Lead or Kubernetes Admin can create a project linked to the right namespaces and give developers a focused space to work all in just a few clicks.

Here is what you can do in the Headlamp UI:

Create a New Project​

Use a guided flow to name your project and define its scope. Projects are built on a label-based model, allowing you to group resources across one or more namespaces. This can of course be done in Headlamp's UI, or by applying the right labels to namespaces in whatever way a cluster administrator prefers.

Import Existing Namespaces​

Select existing namespaces or create new ones to associate with your project right from Headlamp's UI.

Span Projects Across Clusters​

Projects are not limited to a single cluster. You can group resources from multiple clusters into a single project, making it easier to manage workloads in hybrid or multi-cluster environments.

Built-in RBAC Integration​

Headlamp respects Kubernetes RBAC, so users only see and interact with resources they are allowed to manage. No extra configuration is required.

Making Kubernetes Work for Developers​

Once a project is created in Headlamp, developers can join and start deploying workloads with minimal friction. Everything is scoped to the project, so users only see what is relevant to their work, instead of having to navigate cluster-wide views. Headlamp respects Kubernetes RBAC permissions, so developers only see the resources they have access to. If a developer already has access to a namespace, once they use Headlamp to access that cluster, the project will automatically appear for them.

This is especially helpful for new developers or users coming from non-DevOps backgrounds. Instead of having to understand where to look in Kubernetes for their app, they can jump straight into deploying and monitoring their applications. Here is what the onboarding experience with Projects looks like:

Monitor and Troubleshoot​

The project view shows active workloads, logs, events, and metrics that are all scoped to the project. Developers can understand what is happening without needing to dig through cluster-wide data.

Delete with a Single Click​

Projects can be deleted with one click. This helps users start fresh or clean up after a learning session without needing help from an admin.

Manage Multiple Environments​

If you have separate environments for development, test, and production, you can create a project for each and link the relevant namespaces. This gives developers a clear, scoped view of the environment they are working in, reducing confusion and mistakes.

Conclusion and Next Steps​

Many Kubernetes users are application developers, and Kubernetes complexity often comes from organizational challenges, not just technical ones. Setting up environments, managing access, and helping new developers get started can take hours or even days. Headlamp Projects solves this by introducing scoped, visual environments that make onboarding and collaboration faster and easier.

By providing a simple, self-service way to group resources, Headlamp lowers the barrier to entry and makes Kubernetes more approachable for everyone. Dev Leads can create projects and organize resources in minutes, while developers can onboard and deploy without navigating cluster internals. New users can experiment safely and build confidence through guided workflows.

Whether you are running Azure Kubernetes Service (AKS), Elastic Kubernetes Service (EKS), or any other Kubernetes distribution, Headlamp Projects help your team move faster, collaborate better, and focus on building, not fighting the platform.

Tip: If you want to add an existing namespace to a project, simply apply the project label via Headlamp (editing the namespace directly), or you can also use kubectl, as:

kubectl label namespace <namespace-name> headlamp.dev/project-id=<project-id>

To get started, open Headlamp, select Projects in its home view, and create a new project to explore how it can simplify your Kubernetes experience.

Starting with Kubernetes often means juggling cloud accounts, billing concerns, drivers, kubeconfig conflicts, and long waits just to see a pod run. You bounce between terminal commands, YAML files, and cluster views while trying to learn the basics or test a simple change. This is also the case when you are running Kubernetes locally. You have tons of choices, but you have to fiddle with the command line to get started.

The Solution​

Headlamp removes that friction with Local Cluster. You can create and manage a fully functional Kubernetes cluster right from the Headlamp UI. No terminal. No cloud provider. Click to start, experiment safely, and get feedback fast in a graphical and intuitive way.

This approach is great for:

• Developers testing apps before production
• Students and learners trying Kubernetes for the first time
• Anyone who wants a safe sandbox without extra setup or cost

What You Get​

When you create a local cluster in Headlamp, you are spinning up a real Kubernetes cluster on your local machine using Minikube.

Your local cluster is:

• Plain Minikube: No cloud infrastructure needed
• Integrated with Headlamp: Managed entirely through the UI
• Ideal for testing and learning: Manage and troubleshoot applications with Projects, inspect resources, and explore features without setup headaches

Once created, the cluster appears in Headlamp like any other cluster. You can start and stop it, deploy applications, using Projects, and manage workloads in an application-centric view. Projects group related app resources into a single scoped space, making it easier to troubleshoot, monitor, and collaborate without navigating cluster-wide complexity.

Deploy Your App Locally​

Local Cluster gives you a fast inner loop. You try a change, see results, and iterate without waiting on remote environments or wrestling with credentials. Developers can validate workloads before pushing to shared clusters, and learners explore Kubernetes without cloud accounts or command line hurdles. When paired with Projects, this workflow scales beyond experimentation. Projects organize resources into an application-centric view, making collaboration and troubleshooting easier as your local work grows into real applications. Together, they turn Kubernetes from a setup challenge into a streamlined development experience.

Step 1: Install the Minikube Plugin​

Step 2: Create Cluster​

Step 3: Deploy directly into a project!​

Step 4: Observe only what matters to the app!​

Step 5: See relationships with the map!​

Step 6: Edit and iterate safely​

Step 7: Control resources and lifecycle​

Keep Building​

The best way to learn Kubernetes is by doing. Headlamp gives you a safe, fast environment to experiment and grow your skills. Check out the full setup guide for Local Cluster and Projects in the Headlamp Learn docs. Start today and keep building.

FluxCon colocated session​

Title: Reconciling ClickOps and GitOps
Speakers: Joaquim Rocha and Oleksandr Dubenko
Date and time: Monday, November 10, 4:00 PM to 4:25 PM EST
Description: A tour of the Flux UI plugin for Headlamp and how it helps teams manage Flux resources through a friendly UI while keeping GitOps principles intact.

ContribFest​

Title: Power up your CNCF tools with Headlamp
Speakers: Joaquim Rocha and Oleksandr Dubenko
Date and time: Tuesday, November 11, 2:30 PM to 3:45 PM EST
Room: Building B, Level 2, B208
Description: A hands-on session to learn how to create a plugin for Headlamp and discussing any project related subjects. Bring your laptop and ideas.

KubeCon + CloudNativeCon North America 2025​

Title: No kubectl, No Problem: The Future with Conversational Kubernetes
Speaker: Will Case
Date and time: Tuesday, November 11, 5:00 PM to 5:30 PM EST
Room: Building B, Level 2, B206
Description: A look at the Headlamp AI assistant and how natural language can simplify common Kubernetes workflows right inside the UI.

Project Pavilion​

Stop by the Project Pavilion to see live demos and meet maintainers. The Pavilion is located in Building B, Level 1, Exhibit Hall B3 to B5. Our kiosk number is 18A and we will staff it on the three full days of the Project Pavillion.

Join Us​

We look forward to meeting you at KubeCon NA 2025 in Atlanta!

Fixing multi-user authentication issues​

In the initial implementation, the Headlamp instance relied on kubeconfigs managed in the Headlamp backend. While this worked for single-user or demo setups, users noticed problems when multiple people accessed Headlamp simultaneously. Since the kubeconfig file was shared at the backend, access levels got mixed up, for example, one user's kubeconfig could overwrite another's, leading to mismatched permissions and resource visibility.

We've solved this by moving kubeconfig handling to the user's browser. Now, each user session maintains its own cluster access through Headlamp's stateless/dynamic clusters feature. This ensures that:

• Each user's access level correctly reflects their own permissions.
• No kubeconfig is stored or shared on the server side.
• Backend state remains isolated and clean.

This change makes the integration much safer and closer to how Headlamp typically operates in standalone mode.

Integrating with Backstage authentication​

Another pain point users raised was that Headlamp, when spawned as a process, didn't have its own authentication layer, meaning it relied entirely on Backstage's session context, but without verification, which required administrators to take extra measures to secure the deployment.

To fix this, we introduced a proxy layer inside the headlamp-backend plugin. Here's how it works:

• Backstage continues to handle user authentication as usual.
• The headlamp-backend plugin now exposes a proxy endpoint that forwards requests to the Headlamp server.
• Every request passing through this proxy goes through a middleware check that verifies authentication at the Backstage level.
• If the user is not authenticated in Backstage, the request to Headlamp is rejected.

Because all traffic now goes through this proxy, the Headlamp server no longer needs to be exposed externally. It can safely run as an internal process, completely hidden from direct access. This design ensures that Headlamp inherits Backstage’s authentication and access control model, without needing to run a separate auth service or duplicate logic. With these two main changes:

• Per-user kubeconfig handling (via browser sessions)
• Auth-aware proxy middleware between Backstage and Headlamp The integration is now stateless, multi-user safe, and aligned with Backstage's security model.

From a developer's perspective, this also simplifies the deployment. You no longer need to manage shared kubeconfig files or expose the Headlamp server to the outside world. Everything runs behind Backstage's existing authentication and networking layer.

Headlamp's map view provides a visual representation of Kubernetes resources and their relationships directly within Backstage

Detailed pod inspection within Backstage, powered by Headlamp's user-specific authentication

Try it!​

These updates make the Backstage Headlamp integration more secure, predictable, and production-ready for multi-user setups.

We appreciate the community feedback that helped identify these issues and guide the improvements. If you are not yet using Headlamp on Backstage, this update should make your setup simpler and safer, so we encourage you to check the instructions and try it out.

Instructions:

• For the frontend plugin
• For the backend plugin

Whether you're a seasoned engineer or just getting started, the AI Assistant offers:

• Fast time to value: Ask questions like "Is my application healthy?" or "How can I fix this?" without needing deep Kubernetes knowledge.
• Deep insights: Start with high-level queries and dig deeper with prompts like "List all the problematic pods" or "How can I fix this pod?"
• Focused & relevant: Ask questions in the context of what you're viewing in the UI, such as "What's wrong here?"
• Action-oriented: Let the AI take action for you, like "Restart that deployment", with your permission.

Here is a demo of the AI Assistant in action as it helps troubleshoot an application running with issues in a Kubernetes cluster:

Hopping on the AI train​

Large Language Models (LLMs) have transformed not just how we access data but also how we interact with it. The rise of tools like ChatGPT opened a world of possibilities, inspiring a wave of new applications. Asking questions or giving commands in natural language is intuitive, especially for users who aren't deeply technical. Now everyone can quickly ask how to do X or Y, without feeling awkward or having to traverse pages and pages of documentation like before.

Therefore, Headlamp AI Assistant brings a conversational UI to Headlamp, powered by LLMs that Headlamp users can configure with their own API keys. It is available as a Headlamp plugin, making it easy to integrate into your existing setup. Users can enable it by installing the plugin and configuring it with their own LLM API keys, giving them control over which model powers the assistant. Once enabled, the assistant becomes part of the Headlamp UI, ready to respond to contextual queries and perform actions directly from the interface.

Context is everything​

As expected, the AI Assistant is focused on helping users with Kubernetes concepts. Yet, while there is a lot of value in responding to Kubernetes related questions from Headlamp's UI, we believe that the great benefit of such an integration is when it can use the context of what the user is experiencing in an application. So, the Headlamp AI Assistant knows what you're currently viewing in Headlamp, and this makes the interaction feel more like working with a human assistant.

For example, if a pod is failing, users can simply ask "What's wrong here?" and the AI Assistant will respond with the root cause, like a missing environment variable or a typo in the image name. Follow-up prompts like "How can I fix this?" allow the AI Assistant to suggest a fix, streamlining what used to take multiple steps into a quick, conversational flow.

Sharing the context from Headlamp is not a trivial task though, so it's something we will keep working on perfecting.

Tools​

Context from the UI is helpful, but sometimes additional capabilities are needed. If the user is viewing the pod list and wants to identify problematic deployments, switching views should not be necessary. To address this, the AI Assistant includes support for a Kubernetes tool. This allows asking questions like "Get me all deployments with problems" prompting the assistant to fetch and display relevant data from the current cluster. Likewise, if the user requests an action like "Restart that deployment" after the AI points out what deployment needs restarting, it can also do that. In case of "write" operations, the AI Assistant does check with the user for permission to run them.

AI Plugins​

Although the initial version of the AI Assistant is already useful for Kubernetes users, future iterations will expand its capabilities. Currently, the assistant supports only the Kubernetes tool, but further integration with Headlamp plugins is underway. Similarly, we could get richer insights for GitOps via the Flux plugin, monitoring through Prometheus, package management with Helm, and more.

And of course, as the popularity of MCP grows, we are looking into how to integrate it as well, for a more plug-and-play fashion.

Try it out!​

We hope this first version of the AI Assistant helps users manage Kubernetes clusters more effectively and assist newcomers in navigating the learning curve. We invite you to try out this early version and give us your feedback. The AI Assistant plugin can be installed from Headlamp's Plugin Catalog in the desktop version, or by using the container image when deploying Headlamp. Stay tuned for the future versions of the Headlamp AI Assistant!

As part of a Linux Foundation (LFX) Mentorship project, we have built a Headlamp plugin that integrates a UI for viewing and managing KEDA resources directly in the Headlamp dashboard. The plugin was developed by Adwait Godbole, with guidance from the Headlamp team.

Installing KEDA in your cluster​

Before using the plugin, make sure KEDA is installed. You can choose one of these methods:

1. Using Headlamp’s App Catalog: If you’re using Headlamp as a desktop app, you can install KEDA directly from the App Catalog:
   1. Open the Apps Section from the sidebar
   2. Search for KEDA.

3. Click on KEDA app

4. Fill in the required details like name, namespace, and version.

In the YAML editor (which shows the Helm values.yaml), configure the following under prometheus.operator.serviceMonitor:

prometheus:
  operator:
    serviceMonitor:
    enabled: true
    interval: "10s"
    additionalLabels:
        release: prometheus

5. Click Install to finish.

6. Using Helm directly, run the following command:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda \
  --namespace keda \
  --create-namespace \
  --set prometheus.operator.enabled=true \
  --set prometheus.operator.serviceMonitor.enabled=true \
  --set prometheus.operator.serviceMonitor.interval="10s" \
  --set prometheus.operator.serviceMonitor.additionalLabels.release="prometheus"

Installing the KEDA Plugin in Headlamp​

Once KEDA is installed in your cluster:

1. Go to Plugin Catalog → Catalog in the Headlamp home view sidebar.
2. Search for the KEDA plugin and click Install.

Once the plugin is installed, navigate to the Cluster where you have installed KEDA. You’ll see a new KEDA section in the sidebar, where you can view and manage your KEDA resources.

Plugin features​

List view of KEDA resources​

• List all KEDA resource types
  • ScaledObjects
  • ScaledJobs
  • TriggerAuthentication
  • ClusterTriggerAuthentication
• Supports filtering and sorting
• Works across namespaces.

Details View + YAML Editing​

• Shows resource configuration, status, and metadata.
• Linked references (like target workloads or secrets) are shown where applicable. Inline YAML editor for quick updates.

Trigger Metrics (Real-Time)​

• Displays live values from KEDA triggers (e.g. queue length, HTTP request rate).
• Shows current and max replica counts.
• Helps understand if scaling is working as expected.

Map View​

• Visual representation of how KEDA resources relate to each other and to Kubernetes workloads.
• Helps understand the connection between ScaledObjects, triggers, and their targets.

Conclusion​

The KEDA plugin for Headlamp makes it easier to work with event-driven autoscaling by providing a visual and navigable view of KEDA resources like ScaledObjects, ScaledJobs, and trigger authentications. With support for real-time metrics, cross-linked resources, and a built-in map view, you can now understand scaling behavior and troubleshoot issues without switching between tools like Prometheus dashboards or the CLI.

Everything you need to inspect, edit, and monitor KEDA resources is thus available in one place.

If you use KEDA, we encourage you to try the plugin and share feedback or ideas via GitHub.

How one gets started with Kubernetes​

For new users, the learning curve for getting started with Kubernetes can be steep. One first needs to understand different tools such as minikube, kubectl, and hypervisors; all together making it a bit overwhelming. In addition, setting up a local Kubernetes environment often requires familiarity with command-line operations, which can be a barrier for those just starting out. How can we improve that?

Headlamp Desktop: A new starting point for Kubernetes​

Headlamp, aims to simplify the user experience around Kubernetes. To take this to the logical next step, we've created a plugin that allows users to create a local Kubernetes environment using minikube with just one click. This plugin eliminates the need for command-line operations, making it accessible for everyone, regardless of their technical background. In addition, it welcomes users into a visual, interactive Kubernetes environment which they can explore. And using Headlamp's growing number of plugins for CNCF and other projects in the eco-system, users can learn more about the broader Kubernetes ecosystem.

Managing the environment​

The minikube plugin not only installs and starts minikube but also provides additional functionalities. Users can see the status of their minikube cluster directly in the UI and have the ability to start or stop the cluster with ease. This integration ensures that managing your local Kubernetes environment is straightforward and intuitive.

Continuing to Improve the UX​

We are committed to improving the user experience around CNCF projects and lowering the bar for learning Kubernetes. While the minikube plugin is at an early stage, we invite you to install it from the Plugin Catalog in Headlamp Desktop and try it. If you are interested in developing Headlamp plugins for other projects, check out the docs and reach out to us. Your feedback and contributions are invaluable as we strive to make Kubernetes more accessible to everyone.

Thank you for your support, and happy Kubernetes-ing!

Overview page​

A Flux user suggested we add an overview page for the Flux plugin, and we loved the idea. This new page provides a comprehensive summary of your Flux resources, including the version and checks related to Flux’s installation. Additionally, it offers a graphical representation of the health of your deployments, making it easier to manage and monitor them effectively.

Flagger Integration​

We're thrilled to introduce Flagger integration in this update. Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. With this integration, the Flux UI now supports visualizing different update strategies.

New Map View for Flux​

Another exciting addition is the new map view for Flux! We've had a map view in Headlamp for a couple of versions now, and it’s proven to be an excellent way to quickly understand the cluster and its resources' relationships. This feature offers a visual representation of your Flux resources and how they relate to each other, providing a clearer understanding of your deployment architecture.

Bug Fixes and Community Contributions​

This update also includes several bug fixes and improvements, thanks to the contributions from our amazing community members: Stefan Prodan, Kingdon Barrett, Matthijs Galesloot, and George Gaal. We appreciate your guidance, support, and dedication to making the Flux UI better.

Try this update​

To try these new changes, just install or update the Flux UI plugin from the Plugin Catalog, if using the desktop version of Headlamp, or update to the latest container image if you are deploying on the web.

We hope you enjoy this update!

As the Cloud Native Computing Foundation's flagship conference, KubeCon is a fantastic opportunity for the Kubernetes community to come together, share knowledge, and explore the latest advancements in cloud-native technologies.

Headlamp Team Activities​

Our team has a packed schedule of activities planned for KubeCon Europe, and we can't wait to connect with the community. Here are some of the highlights:

• Headlamp as a UI for all Kubernetes users and projects: Join us for a quick session at the wonderful Microsoft booth, where we'll provide a brief overview of Headlamp and discuss how other projects can benefit from it.
  • Microsoft Booth Theater Session
  • April 2nd, 2:30pm
• Headlamp Kiosk at the Project Pavilion: Come join us and check out demos of Headlamp, chat with the team and take some swag home!
  • Kiosk 22B, Level 1 | Solutions Showcase | Hall Entrances N8 – N9
  • April 2nd, 10:45am – 7:45pm
• Contribfest: Make Your Own UI for Kubernetes with Headlamp: Join us for this engaging session designed for those looking to learn how to create their own UI for Kubernetes using Headlamp. It's a great opportunity to dive into the details and get hands-on experience. We may have chocolate.
  • Level 3, ICC Capital Suite 1
  • April 4th, 11:00am

Special Mention: Microsoft Keynote​

We're excited to highlight a special keynote from Microsoft during KubeCon Europe. The keynote, titled "Evolving the Kubernetes User Experience," will be presented by Andrew Randall on Wednesday, April 2, 2025, from 09:49 to 09:54 BST at Level 0, ICC Auditorium.

Meet the Headlamp Team​

If you're passionate about advancing the state of UI and UX around Kubernetes, we invite you to meet us at KubeCon Europe. Whether you're a developer, designer, or just curious about Kubernetes, we'd love to hear your ideas and discuss how we can work together to make Headlamp even better.

Thank you for your continued support, and we look forward to seeing you in London!

To enhance the user experience of managing certificates in Kubernetes, we've developed a Headlamp plugin for cert-manager. This plugin brings certificate management directly into Headlamp, allowing developers to view and manage cert-manager resources.

Installing cert-manager in the cluster​

If you don't have cert-manager installed in your cluster, you can install it in two ways:

Using Headlamp's App Catalog​

If you're using Headlamp as a desktop app, you can install cert-manager directly from the App Catalog:

1. Access the Apps section from the sidebar after connecting to your cluster.
2. Search for the cert-manager app.
3. Click Install.

Using Helm​

Alternatively, you can install cert-manager using Helm by running these commands:

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

## Install cert-manager with CRDs

helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--set installCRDs=true

Installing the cert-manager plugin​

1. In Headlamp's home screen, click on Plugin Catalog > Catalog.
2. Find the cert-manager plugin and click Install.

Plugin features​

The cert-manager plugin allows users to list and view details of resources like Certificates, Certificate Requests, Issuers, ClusterIssuers, Orders, and Challenges. The resource details view also links to corresponding Kubernetes resources like Secrets and Ingresses, making it easy to navigate between related resources.

Looking Ahead​

This is just the beginning! We’re continuously working on improving the cert-manager plugin based on user feedback. If you have suggestions or encounter any issues, please contribute via GitHub or join our Slack channel.

Try the cert-manager plugin for Headlamp today and simplify your Kubernetes certificate management! 🚀

Security is at the core of these features with both catalogs incorporating ArtifactHub’s badging system, including verified, official, and CNCF project designations. These visual indicators, combined with verified publisher filtering, give users confidence in selecting high-quality and secure Helm charts and Headlamp plugins.

Badges​

Verified Badge: This checkmark indicates that the repository publisher owns or has control over the repository associated with this package (Helm chart or Plugin).

Official Badge: Marked by a star, this badge signifies that the publisher owns the software or project that the package primarily focuses on.

CNCF Badge: The Cloud Native Computing Foundation Badge, signifies that the Helm chart or plugin is associated with a project under the CNCF.

Here is an example of a Helm chart displayed with all three badges in the App Catalog:

Other UI Changes​

Additionally, with the introduction of these badges we provide users with the option to filter results in both plugins via a switch. In the case of the App Catalog the switch shows whether only verified plugins are shown, while in the case of the Plugin Catalog there are two switches, for controlling showing not only verified but also official plugins.

It is vital that users install only plugins they trust, so this switch is on by default in both cases, meaning that only verified + official plugins or plugins developed by Headlamp’s core developers are shown. While this limits the results and options for the user, it also improves the confidence in the results being shown, reducing the possibilities of installing undesired packages. And of course, users can always choose to show everything by going to the settings view of each plugin.

These switches are located in the settings view for each plugin. You can access it by going to Settings > Plugins (in the home view) and then clicking the respective plugin name. In the case of the Plugin Catalog, we have also added the same switch to the actual catalog's page, since there are plugins that cannot get the official badge (because they are done by a 3rd party, see for example the KubeEscape plugin) but which users may still trust and wish to install. To help users understand this decision, when the official switch is turned off for the Plugin Catalog, a dialog is shown explaining that the users should make sure they trust the plugins:

Conclusion​

These additions not only reduce risks but also speed up the selection process. By putting key details front and center, these updates make navigation easier and enhance security.

We’d love for you to explore these updates! If you have ideas for other small changes that could improve clarity or security, we’re eager to hear your feedback and contributions.

About​

Instead of working with tables or YAML files, you can now visually explore the connections between the Kubernetes resources. For example, you can see which pods are linked to which services or how deployments relate to replica sets. This makes it much simpler to understand your cluster’s structure.

When troubleshooting, the Map View is especially useful. If a pod fails, you can find which services or deployments depend on it, helping you identify the cause of the issue.

Examples​

In addition to the demo videos, here are some screenshots highlighting Map features.

Conclusion​

The Map View offers an intuitive way to explore and manage Kubernetes clusters. By visually representing components and their interactions, it simplifies troubleshooting and helps optimize your setup. Whether you're experienced or new to Kubernetes, it’s a helpful tool to better understand your cluster. In the future we're planning on providing APIs for plugins, allowing you to extend the Map View with extra details. If you have ideas or suggestions of what you'd like to see added to the Map open a feature request on GitHub or message us on Slack. Try out Headlamp with Map view now.

In this post, we will explore the recent security improvements we have implemented, including the addition of a value schema, signing of Helm charts, and verified and official publisher status in ArtifactHub. These enhancements not only increase the security of Headlamp deployments but also align with best practices in the Kubernetes ecosystem.

Understanding the Current Security Landscape​

Before diving into our specific enhancements, it is important to understand the broader security concerns in Kubernetes and how they relate to Helm charts.

Kubernetes environments face various security challenges, including:

• Unauthorized access to clusters and resources.
• Misconfigured RBAC policies.
• Exposed sensitive information in ConfigMaps or Secrets.
• Container vulnerabilities and outdated images.
• Network policy misconfigurations.

When it comes to Helm charts, additional security considerations come into play:

• Integrity of chart sources.
• Validation of chart values.
• Proper handling of sensitive data.
• Version control and update management.

These challenges highlight the necessity for strong security measures in Kubernetes setups, particularly when using Helm for application management.

Key Security Enhancements​

Value Schema Addition​

One of the significant improvements we have made is the addition of a value schema to Headlamp's Helm chart. This enhancement provides several benefits:

• Improved validation of user-supplied values.
• Clear documentation of available configuration options.
• Reduced risk of misconfigurations due to typos or incorrect value types.

Using a value schema has simplified user understanding and correct configuration of Headlamp, lowering the risk of security issues from misconfiguration.

Signing of Helm Charts​

To ensure the integrity and authenticity of Headlamp's Helm chart, we have implemented chart signing. This process involves:

• Cryptographically signing the chart package using gpg keys.
• Enabling verification of the chart's origin and integrity using gpg fingerprint.

The benefits of this enhancement include:

• Assurance that the chart has not been tampered with.
• Verification of the chart's source.

Compliance with security best practices for software distribution.

Verified + Official Status on ArtifactHub​

Headlamp has verified and official publisher status for its Helm chart on ArtifactHub, which adds an extra layer of trust for users. This status brings several advantages:

• Increased trust in the Headlamp chart.
• Easier discovery of Headlamp in Helm repositories.

Implementation Guide​

Value Schema Addition in Headlamp's Helm Chart​

1. Schema Structure: The values.schema.json file uses JSON Schema syntax to define the structure of the values. It typically includes:
   • $schema: Specifies the JSON Schema version being used
   • type: Usually set to "object" for the root level
   • properties: Defines the individual configurable values
2. Data Types: Each property in the schema is assigned a specific data type, such as:
   • string
   • number
   • boolean
   • array
   • object
3. Validation Rules: The schema can include various validation rules, such as:
   • required: Specifies which properties are mandatory
   • minimum and maximum: For numeric values
   • minLength and maxLength: For string values
   • pattern: Regex patterns for string validation
   • enum: List of allowed values
4. Default Values: While default values are typically defined in values.yaml, the schema can include a default field for each property to document the default value.
5. Descriptions: Each property can include a description field, providing documentation directly in the schema.
6. Nested Structures: For complex configurations, the schema can define nested objects and arrays, mirroring the structure of the values.yaml file.

Integration with Helm​

1. Placement: The values.schema.json file is placed in the root directory of the Helm chart.
2. Helm Validation: Helm automatically uses this schema to validate values during helm install, helm upgrade, and helm template operations.
3. CI/CD Integration: The schema can be used in CI/CD pipelines to validate values before deployment.

Benefits in Practice​

1. Error Prevention: Helm will throw an error if provided values do not conform to the schema, preventing misconfigurations from being applied to the cluster.
2. IDE Support: Many IDEs can use the schema to provide auto-completion and inline documentation when editing values.yaml files.
3. Documentation: The schema serves as a form of self-documentation, clearly defining what can be configured and how.
4. Versioning: As the Helm chart evolves, the schema can be versioned alongside it, clearly indicating changes in configuration options.

Challenges and Considerations​

1. Maintenance: The schema needs to be kept in sync with the actual chart templates and default values.
2. Complexity: For charts with many configurable options, the schema can become quite large and complex.
3. Backward Compatibility: Changes to the schema need to be managed carefully to maintain backward compatibility or to clearly communicate breaking changes.

Example Structure​

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "replicaCount": {
      "type": "integer",
      "description": "Number of replicas to deploy",
      "minimum": 1
    },
    "image": {
      "type": "object",
      "title": "Image",
      "description": "Image to deploy",
      "properties": {
        "registry": {
          "type": "string",
          "description": "Registry of the image"
        },
        "repository": {
          "type": "string",
          "description": "Repository of the image"
        },
        "pullPolicy": {
          "type": "string",
          "description": "Pull policy of the image",
          "enum": ["Always", "IfNotPresent", "Never"]
        },
        "tag": {
          "type": "string",
          "description": "Tag of the image"
        }
      }
    }
  }
}

Signing of Helm charts using gpg keys​

Signing Helm charts ensures the integrity and authenticity of the chart package. Headlamp uses GPG (GNU Privacy Guard) for signing, integrated into the GitHub Actions workflow for automated signing during the release process.

Key Components​

• GPG Key: A GPG key pair (public and private) used for signing.
• GitHub Secrets: Storing sensitive information like GPG keys and passphrases.
• chart-releaser-action: A GitHub Action for releasing Helm charts.
• Chart.yaml: Helm chart metadata file, including signing information.

Key Components​

1. GPG Key Preparation

The workflow prepares the GPG key for signing:

- name: Prepare GPG key
  run: |
    gpg_dir=.cr-gpg
    mkdir "$gpg_dir"

    # referring keyring to private key of gpg
    keyring="$gpg_dir/secring.gpg"

    # storing base64 GPG key into keyring
    base64 -d <<< "$GPG_KEYRING_BASE64" > "$keyring"

    passphrase_file="$gpg_dir/passphrase"

    # storing passphrase data into a file
    echo "$GPG_PASSPHRASE" > "$passphrase_file"

    # saving passphrase into github-environment
    echo "CR_PASSPHRASE_FILE=$passphrase_file" >> "$GITHUB_ENV"

    # saving private key into github-environemnt
    echo "CR_KEYRING=$keyring" >> "$GITHUB_ENV"
  env:
    GPG_KEYRING_BASE64: "${{ secrets.GPG_KEYRING_BASE64 }}" #Referring secrets of github above
    GPG_PASSPHRASE: "${{ secrets.GPG_PASSPHRASE }}"

Key points:

• The GPG private key is stored as a base64-encoded secret in GitHub.
• The key is decoded and stored in a temporary file.
• The passphrase is stored in a separate file.
• Environment variables are set for the chart-releaser action.

2. Chart Signing with chart-releaser-action

The chart-releaser-action is used to sign and release the chart:

- name: Run chart-releaser
  uses: helm/chart-releaser-action@a917fd15b20e8b64b94d9158ad54cd6345335584 # v1.6.0
  env:
    CR_TOKEN: "${{ github.token }}"
    CR_KEY: "${{ secrets.GPG_SIGNING_KEY_NAME }}" # Name used while creating key
    CR_SIGN: true # set to true to sign images
  with:
    config: .github/cr.yaml
    mark_as_latest: false # only headlamp is set to latest

Key points:

• CR_SIGN: true enables chart signing.
• CR_KEY specifies the name of the GPG key to use for signing.
• The action uses the prepared GPG key and passphrase for signing.

3. Chart.yaml Configuration

The Chart.yaml file includes metadata about the signing key:

annotations:
  artifacthub.io/signKey: |
    fingerprint: 2956B7F7167769370C93730C7264DA7B85D08A37
    url: https://keys.openpgp.org/vks/v1/by-fingerprint/2956B7F7167769370C93730C7264DA7B85D08A37

Key points:

• The fingerprint is the unique identifier of the GPG key used for signing.
• The URL points to a public key server where the public key can be retrieved.

Technical Details​

• GPG Key Generation:

  • A GPG key pair is generated offline.
  • The public key is uploaded to a public key server (in this case, keys.openpgp.org).
  • The private key is base64 encoded and stored as a GitHub secret.

• GitHub Secrets Configuration:

  • GPG_KEYRING_BASE64: The base64-encoded private GPG key.
  • GPG_PASSPHRASE: The passphrase for the GPG key.
  • GPG_SIGNING_KEY_NAME: The name associated with the GPG key.

• Workflow Execution:

  • The workflow decodes the GPG key and sets up the environment.
  • chart-releaser-action uses this environment to sign the chart during the release process.

• Signing Process:

  • The chart package (.tgz file) is signed, creating a .prov file.
  • The .prov file contains a PGP signature that can be used to verify the chart's integrity.

• Verification:

  • Users can verify the chart using the public key available at the URL specified in Chart.yaml.
  • Verification can be done using helm verify command or by manually checking the PGP signature.

Security Considerations​

1. Key Management: Secure storage and rotation of GPG keys are crucial.
2. GitHub Secrets: Access to GitHub secrets should be strictly controlled.
3. Public Key Distribution: Ensure the public key is readily available for users to verify charts.

Benefits​

1. Integrity: Detects any tampering with the chart package.
2. Authenticity: Verifies that the chart comes from a trusted source.
3. Trust: Builds confidence in the Headlamp Helm chart among users.

By implementing this signing process, Headlamp ensures that its Helm charts are verifiably authentic and untampered, enhancing security and trust in the Kubernetes community.

ArtifactHub Verified + Official Publisher Status​

The Verified and Official Publisher status on ArtifactHub is a way to certify the authenticity and ownership of packages, including Helm charts. This status is represented by a blue badge on the ArtifactHub interface, indicating that the publisher has gone through a verification process.

Key Components​

• artifacthub-repo.yml: This needs to have information about your
• Chart.yaml file with comprehensive metadata including maintainer information
• Repository indexed: To ensure optimal discoverability and integration, we implemented robust repository indexing practices.

Process Details​

1. Metadata Configuration:

Create a artifacthub-repo.yml file in your Helm chart repository. For example, the Headlamp repository yaml is located at the gh-pages branch.

repositoryID: de353ebb-8d3f-4717-9813-b3ec4621a93b
owners:
- name: OWNER_NAME
  email: OWNER_EMAIL

2. Chart Metadata

Ensure that your Chart.yaml file includes the accurate metadata.

maintainers:
- name: <maintainer-name>
   email: <maintainer-email>

3. Repository Indexing

Ensure your Helm repository is properly indexed. You need to run command helm repo index . to properly index it.

Benefits of Verified + Official Publisher Status​

• Enhanced Visibility: Verified and official Helm charts appear higher in search results.
• User Trust: The badge signals reliability and authenticity to users.
• Community Standing: Demonstrates commitment to quality in the Kubernetes ecosystem.
• Security Assurance: Implies regular security audits and best practices.

By maintaining Verified and Official Publisher status, Headlamp demonstrates its commitment to providing secure, reliable, and well-maintained Helm charts to the Kubernetes community.

Impact and Benefits​

These security enhancements significantly improve Headlamp's overall security posture:

• Reduced risk of misconfigurations and associated vulnerabilities.
• Increased confidence in the integrity of Headlamp deployments.
• Better alignment with industry security standards and best practices.
• From a user experience perspective, these improvements offer:
• Clearer configuration options and validation.
• Increased trust in Headlamp as a secure Kubernetes UI solution.

Conclusion​

In this post, we have explored the recent security enhancements to Headlamp's Helm chart, including the addition of a value schema, implementation of chart signing, and achievement of verified and official publisher status. These improvements demonstrate our commitment to providing a secure, reliable Kubernetes dashboard solution.

Looking ahead, we are continually evaluating and improving our security measures. Future enhancements may include:

• Enhanced RBAC configurations.
• Automated security scanning and reporting using plugin.

We encourage you to upgrade to the latest version of Headlamp's Helm chart to take advantage of these security enhancements. As always, we welcome your feedback and contributions to make Headlamp even better.

Accessing the settings​

Previously, accessing settings from the sidebar in the home view would take you to the general settings, without the option to view or configure the settings for any clusters you had set up. Now, the settings experience has been improved and consolidated. Simply click on the "Settings" button in the sidebar from the home view, and you'll be taken to the general settings, with easy access to plugin and cluster settings as well. If you're navigating from within a specific cluster, the "Settings" button now takes you directly to that cluster's settings, just like before. But of course, the general settings are still accessible from the sidebar.

You can also access the settings for any of the clusters you have set up, without having to navigate to them individually, since we've added a selector to choose the cluster for which to show the settings. There is also a link on the right side to quickly access that cluster.

Conclusion​

Headlamp strives to cover a wide range of use cases, from web deployments to Docker Desktop and more. Sometimes, this flexibility leads to parts of the UI that need refinement as new use cases emerge. By unifying the settings into one place, we've addressed a long-standing UX challenge, making Headlamp easier to navigate and configure. We're always looking to improve, so if you encounter any UX issues or have suggestions, we would love to hear from you (file an issue, or chat with us on Slack). Until next time!