Unauthenticated Kubernetes Dashboard Access in Bug Bounty
The Kubernetes Dashboard is a convenience UI that should never face the internet without strong auth. Hunters still find it on forgotten ingresses, node ports, and "temporary" LoadBalancers left for debugging.
You open https://k8s-dash.target.tld and land on a token form—or worse, skip auth entirely. What next?
Confirm what "open" means
Unauthenticated can mean different failures:
- No login prompt; namespace list loads immediately
- Login accepts empty token or a well-known service account
- Skip button still present on older builds
- OIDC configured, but anonymous GETs still return workload metadata
- Dashboard proxied behind basic auth with a default password
Record the product version from the UI or static assets. Older Dashboards shipped with a skip option that granted the service account backing the pod. That SA's RBAC is the real severity dial.
Stay read-only. Screenshot workload names you are allowed to see, redact customer identifiers, and stop before Exec, Delete, or Apply. Creating a pod to "prove RCE" turns a clean finding into an incident.
If the UI offers a token paste field, try a clearly invalid token first and capture the error. Then, only if scope allows, test whether a low-priv token from another finding elevates through the Dashboard's proxy. Confused-deputy issues show up here: the browser talks to the Dashboard, and the Dashboard talks to the API with a broader identity.
Recon tips that actually work
Search certificate transparency and DNS for dashboard, k8s, kubernetes, lens, and vendor UI names. Probe common paths: /, /#/login, /api/v1/namespace, and proxied API prefixes. Try the hostname over both HTTP and HTTPS; some clusters terminate TLS on a different name.
If you have a weak foothold elsewhere, check whether an internal Dashboard Service is reachable via SSRF or a miswired ingress. ClusterIP alone is not a finding from the public internet; an ingress that publishes it is.
Compare what anonymous users see versus what a stolen low-priv token sees. Sometimes the UI hides controls while the proxied Kubernetes API still answers list calls. Hit the API paths the Dashboard uses and note authorization errors versus data.
NodePort and hostPort leftovers are easy to miss when the pretty ingress requires SSO. Scan the same IP ranges the company uses for other in-scope assets. A Dashboard on a high port next to an app you already test is still in play if the policy covers the domain or IP.
Report like an operator will read it
Structure the write-up as: public URL → auth state → identity used by the Dashboard → sample of readable resources → why that matters (secret names, deploy controls, exec capability if shown but not used).
Include response headers, the ingress class if visible, and whether metrics or health endpoints leak cluster names without login. Recommend removing public exposure, putting the UI behind SSO with MFA, binding a least-privilege Dashboard SA, disabling skip/login-less modes, and preferring kubectl with short-lived creds for break-glass work.
Curious why this keeps recurring? Because "just for staging" ingresses outlive the sprint. Treat every cluster UI as production until auth proves otherwise.