Originally published on kuryzhev.cloud
We found our Kubernetes Dashboard sitting on a NodePort, reachable from the internet, during a routine Shodan sweep we ran against our own IP ranges. No VPN in front of it, no Access policy, just `kubectl proxy --address=0.0.0.0` leftover from a debugging session three weeks earlier. That's the scenario that pushed us to build a Kubernetes Dashboard Cloudflare Tunnel setup and turn it into a repeatable checklist instead of a one-off fix.
Why this checklist
Exposing Kubernetes Dashboard directly — via NodePort, LoadBalancer, or an open kubectl proxy — is one of the most common ways clusters get taken over. Censys and Shodan both index thousands of dashboards with default configs, and if the ClusterRoleBinding is cluster-admin (which it often is out of the box), an attacker with dashboard access has full cluster access. We've seen this in the wild on client audits more than once.
The traditional fix is a VPN: WireGuard or OpenVPN in front of the cluster, client software on every laptop, IP allowlists that break the moment someone works from a coffee shop. It works, but it's heavy for what is really a single-app access problem. Cloudflare Tunnel plus Zero Trust Access solves this differently — cloudflared makes an outbound-only connection from inside the cluster to Cloudflare's edge, so there's nothing to open inbound at all. Access then sits in front of the tunnel hostname and enforces identity per request, not per network.
