The Kubernetes web dashboard add-on is deprecated, often runs with broad permissions, and gives attackers a graphical entry point into your cluster if exposed. Disable it with gcloud container clusters update CLUSTER --update-addons=KubernetesDashboard=DISABLED and rely on the Cloud Console or kubectl instead.
The Kubernetes web dashboard was once the default way to click around your cluster, scale deployments, and read logs without touching the command line. On GKE it ships as an optional add-on, and a lot of older clusters still have it switched on because someone enabled it during a demo years ago and never turned it back off. This check flags any GKE cluster where that add-on is still active.
That convenience comes with a real cost. The dashboard has a long history of security problems, Google deprecated the add-on, and the Kubernetes project itself recommends against exposing it. If you are running it, you are carrying risk you almost certainly do not need.
What this check detects
The gke_webdashboard check inspects each GKE cluster's add-on configuration and reports a failure when the kubernetesDashboard add-on is enabled. In the cluster resource this shows up as:
{
"addonsConfig": {
"kubernetesDashboard": {
"disabled": false
}
}
}
When disabled is false, GKE deploys the dashboard into the kube-system namespace along with a service account that backs it. The check does not care whether the dashboard is currently reachable from the internet. The mere presence of the workload and its associated permissions is enough to count as a finding.
Note: Google deprecated the Kubernetes dashboard add-on in GKE and disables it by default on newer clusters. If your cluster has it on, it was either created a long time ago or someone explicitly enabled it.
Why it matters
The dashboard is not dangerous because it exists. It is dangerous because of what it can do and how easy it is to misuse.
It has a track record of being abused
The most famous example is the 2018 Tesla incident, where attackers found a Kubernetes dashboard exposed without authentication, walked straight into the cluster, and used it to run cryptocurrency mining. The dashboard's own service account had enough access to read secrets, which included cloud credentials. That was not a zero-day. It was a default add-on left exposed.
Authentication is easy to get wrong
The dashboard supports token and kubeconfig login, but plenty of deployments skip authentication entirely or grant the dashboard service account cluster-admin so that "everything just works." A service account with cluster-admin can read every secret in every namespace, create pods, and pivot to your node service accounts. If the GKE node service account has broad GCP IAM permissions, an attacker who reaches the dashboard can often escalate from the cluster into your wider GCP project.
Danger: A dashboard backed by a cluster-admin service account is effectively a full cluster takeover waiting to happen. Anyone who reaches it, through a misconfigured ingress, a leaked token, or a compromised pod, can read every secret and schedule arbitrary workloads.
It widens your attack surface for no benefit
The dashboard is deprecated, and everything it does is available through the GKE Console UI in Google Cloud and through kubectl. Running it means maintaining an extra public-facing workload, an extra service account, and an extra set of RBAC bindings, all of which you have to keep patched and locked down. That is maintenance burden and risk with no upside.
How to fix it
Disabling the add-on is the right move in almost every case. The fix is fast and does not affect your running workloads.
Option 1: gcloud CLI
Warning: Updating add-ons triggers a control plane reconfiguration. Your workloads keep running, but management operations on the cluster may be briefly unavailable. Run this during a low-traffic window if you are cautious about it.
gcloud container clusters update CLUSTER_NAME \
--update-addons=KubernetesDashboard=DISABLED \
--zone=COMPUTE_ZONE \
--project=PROJECT_ID
For a regional cluster, swap --zone for --region:
gcloud container clusters update CLUSTER_NAME \
--update-addons=KubernetesDashboard=DISABLED \
--region=COMPUTE_REGION \
--project=PROJECT_ID
Confirm it took effect:
gcloud container clusters describe CLUSTER_NAME \
--zone=COMPUTE_ZONE \
--format="value(addonsConfig.kubernetesDashboard.disabled)"
A value of True means the dashboard is disabled. GKE will remove the dashboard deployment from kube-system as part of the update.
Option 2: Google Cloud Console
- Open Kubernetes Engine > Clusters and select your cluster.
- Go to the Details tab and find the Features section.
- Locate Kubernetes dashboard (deprecated) and click the edit pencil.
- Set it to Disabled and save.
Option 3: Terraform
If you manage GKE with Terraform, set the add-on explicitly so it never drifts back on:
resource "google_container_cluster" "primary" {
name = "production-cluster"
location = "us-central1"
addons_config {
kubernetes_dashboard {
disabled = true
}
}
}
Run terraform plan to confirm the change, then terraform apply. Keeping this block in your config means a future terraform apply will revert anyone who re-enables the dashboard by hand.
Tip: If you genuinely want a graphical view of your cluster, use the built-in Workloads, Services, and Object Browser views in the GKE Console. They are authenticated through your Google identity and IAM, so there is no separate token or service account to manage.
How to prevent it from coming back
Fixing one cluster is easy. Stopping the dashboard from creeping back into new clusters across your fleet takes a little policy work.
Lock it down in your cluster modules
If every cluster comes from a shared Terraform module, hardcode the add-on as disabled in that module. Teams that consume the module cannot turn it on without editing shared infrastructure code, which means it goes through review.
Enforce it with Policy Controller or OPA Gatekeeper
For organization-wide enforcement, use GKE Policy Controller or Anthos Config Management to reject cluster configs that enable the dashboard. You can also block deployment of the dashboard workload at admission time. A simple Gatekeeper constraint that denies any deployment named kubernetes-dashboard in kube-system catches manual reinstalls:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockedResources
metadata:
name: block-k8s-dashboard
spec:
match:
kinds:
- apiGroups: ["apps"]
kinds: ["Deployment"]
namespaces: ["kube-system"]
parameters:
blockedNames: ["kubernetes-dashboard"]
Gate it in CI/CD
Add a check to your pipeline that scans Terraform plans or live cluster configs before they merge. A small script using gcloud or a tool like checkov can fail the build when the dashboard add-on is enabled:
# Fail the pipeline if any cluster has the dashboard enabled
gcloud container clusters list \
--format="value(name,addonsConfig.kubernetesDashboard.disabled)" \
| awk '$2 != "True" { print "Dashboard enabled on " $1; exit 1 }'
Tip: Lensix runs the gke_webdashboard check continuously, so even if a cluster is created outside your pipeline or someone toggles the add-on by hand, you get a finding instead of discovering it during an incident.
Best practices
- Treat deprecated add-ons as off by default. If Google has deprecated something and turns it off on new clusters, that is a strong signal to remove it from existing ones too.
- Use IAM-backed access instead of standalone tools. The GKE Console honors your Google Cloud IAM and Kubernetes RBAC. That gives you audit logging and least privilege without a separate credential to leak.
- Scope node and workload service accounts tightly. Much of the dashboard's danger comes from over-privileged service accounts. Give your nodes and pods only the permissions they actually need, so a cluster foothold does not become a project-wide one.
- Never expose cluster management UIs to the public internet. If you must run an internal management tool, put it behind an authenticated proxy, IAP, or VPN, never a public load balancer.
- Audit add-on configuration across the whole fleet. A single misconfigured cluster is the one that gets hit. Continuous, fleet-wide checking is what catches the outlier you forgot about.
Disabling the GKE web dashboard is one of the lowest-effort, highest-value hardening steps you can take on a Kubernetes cluster. It removes a deprecated, frequently abused entry point, costs you nothing in lost functionality, and takes a single command. Turn it off, enforce that it stays off, and move on to harder problems.