YAKD Dashboard: Deep Dive

This document explains why Kubernetes dashboards matter, how YAKD works under the hood, and what security trade-offs you accept when you deploy it.

Why Dashboards Exist

kubectl is powerful. It is also a wall of text.

When you run kubectl get pods -A, you get a list. When you run kubectl describe pod <name>, you get a long dump of events, conditions, volumes, and labels. Parsing that output to understand what is happening across a cluster takes practice. For experienced operators, kubectl is fast. For everyone else, it is a firehose.

Dashboards provide spatial awareness. You can see all namespaces at once, click into a pod to see its logs, and spot a failing deployment by the red status indicator. This is not about replacing kubectl. It is about giving you a different view of the same data.

Think of it this way: kubectl is a debugger. A dashboard is a monitoring screen. Both show cluster state. One is better for targeted investigation. The other is better for “what is going on right now.”

How YAKD Works

YAKD is a single container running two things: a Quarkus (Java) backend and a React frontend.

Browser
  |
  v
React Frontend (static files served by Quarkus)
  |
  v
Quarkus Backend
  |
  v
Kubernetes API Server

The backend uses the Kubernetes client library to talk to the API server. It requests pod lists, deployment statuses, service definitions, and config maps. The frontend polls the backend and renders the results.

The key design choice: YAKD is read-only. You cannot edit resources, scale deployments, or delete pods from the UI. This limits risk. A dashboard that can modify cluster state is a dashboard that can accidentally break your cluster.

From the deployment manifest:

containers:
  - name: yakd
    image: marcnuri/yakd:0.0.8
    ports:
      - containerPort: 8080
    securityContext:
      allowPrivilegeEscalation: false
      runAsUser: 1001
      runAsGroup: 2001

Notice the security context. The container runs as a non-root user (1001) with privilege escalation disabled. This is good container hygiene, even for a read-only tool.

The cluster-admin Problem

YAKD needs to read resources across every namespace. The RBAC configuration gives it cluster-admin:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: yakd-dashboard
roleRef:
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: yakd-dashboard
    namespace: yakd-dashboard

cluster-admin is the most powerful role in Kubernetes. It can read, write, and delete anything. YAKD only needs read access, but it uses the broadest possible permission.

Why? Simplicity. Creating a custom ClusterRole that grants read-only access to every resource type (pods, deployments, services, configmaps, secrets, events, nodes, namespaces, and so on) requires listing dozens of API groups and resources. cluster-admin covers everything in one line.

The trade-off is real. If someone compromises the YAKD pod or its service account token, they have full cluster access. For a local Minikube cluster, this is fine. For a shared or production cluster, you should create a custom read-only ClusterRole instead.

A minimal read-only role would look something like:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: yakd-readonly
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]

This grants read access to core resources without any write or delete capability.

YAKD vs Headlamp vs kubectl

Each tool serves a different use case:

	YAKD	Headlamp	kubectl
Setup	Apply 4 manifests	Helm install + token	Already installed
Auth	None (uses ServiceAccount)	Token-based login	Kubeconfig
Access	Read-only	Read and write	Full control
Plugins	No	Yes	Yes (via krew)
Multi-cluster	No	Yes	Yes (via contexts)
Best for	Quick local inspection	Team environments	Everything

Use YAKD when you want a fast, zero-config visual overview of a local cluster. No login screens, no token generation. Apply the manifests and open the browser.

Use Headlamp when multiple people need dashboard access with different permission levels. Its token-based auth means you can give one person read-only access and another person full control.

Use kubectl when you need precision. Dashboards are great for browsing, but scripting, piping output, and automating workflows require the CLI.

How YAKD Compares to the Official Dashboard

The official Kubernetes Dashboard is the oldest and most established option. It supports authentication, RBAC, resource editing, and exec into pods. It is also heavier. The install includes multiple deployments, services, and config maps.

YAKD trades features for simplicity. One pod, one service, one RBAC binding. No authentication, no write access, no exec. It starts in seconds and uses minimal resources (128Mi memory request vs the official dashboard’s more complex setup).

For learning and local development, YAKD’s simplicity is an advantage. You spend zero time configuring authentication and go straight to exploring your cluster. For anything beyond a personal dev cluster, the official dashboard or Headlamp are better choices because they enforce who can see what.

When to Deploy YAKD

YAKD fits a specific niche: local development and learning environments where speed and simplicity matter more than security and features.

Deploy it alongside your other demos. Run the Redis demo, the simple app, or any other lab. Then open YAKD and browse the namespaces, pods, and services those demos create. Seeing resources in a visual layout reinforces what kubectl output tells you in text form.

Just remember to clean up the ClusterRoleBinding when you are done. Unlike namespaced resources, ClusterRoleBindings survive namespace deletion:

kubectl delete namespace yakd-dashboard
kubectl delete clusterrolebinding yakd-dashboard

Both commands are necessary for a complete cleanup.