Your Kubernetes dashboard, Portainer, or MinIO console is on the public internet

There's a tier of admin panel above phpMyAdmin and Grafana. Those manage a database or a dashboard. This tier manages the machines, the containers, and the storage that everything else runs on. A leaked one isn't access to an app. It's access to the platform the apps live in.

Kubernetes Dashboard. Portainer. MinIO Console. Redis Commander. RabbitMQ Management. Traefik. These are the control planes for your infrastructure, and they end up on the public internet far more often than you'd hope, usually because spinning one up is easy and locking it down is a separate step nobody got back to.

What's behind each door

These panels don't show you data. They give you control. The severity is high to critical because the actions they allow are the actions an attacker would otherwise need a full compromise to reach.

The Kubernetes Dashboard is the sharpest. If it's reachable and the service account behind it is over-permissioned, which is depressingly common, a stranger can list every pod, read the secrets mounted into them, exec a shell into a running container, and deploy their own workload into your cluster. That last one is the prize for cryptominers: a public, writable Kubernetes Dashboard is free compute, and there are botnets that do nothing but scan for them. MinIO Console is the storage equivalent: it's the admin UI for an S3-compatible object store, and an open one lets a stranger browse and download every object, which is usually your uploads, your backups, and your exports.

Why they're public when they shouldn't be

These tools are built to be run somewhere reachable, and the default "reachable" is wider than people assume.

You deploy Portainer to manage your Docker host, expose it on a port to reach it from your laptop, and that port is open to the whole internet, not just you. You install the Kubernetes Dashboard following a quickstart that proxies it out, and the proxy stays. You run MinIO and the console binds to a public interface because that was the path of least resistance. Redis Commander and RabbitMQ's management plugin get switched on for debugging and left on. None of these announce that they're exposed; they just sit there answering, and the way you find out is either a scan or a breach. Conceptually this is the same problem as a public Grafana or Jenkins, one level deeper into the stack: instead of a monitoring panel, it's the orchestrator the monitoring panel watches.

Take them off the public internet

The fix is the same for all of them, and it's a network decision more than a config one: these panels should never be reachable from the open internet. They sit behind a VPN, on a private network, or bound to localhost and reached through an SSH tunnel.

# docker-compose: console published to every interface
ports:
- "9001:9001"   # MinIO console on 0.0.0.0, public
- "9000:9000"   # Portainer, same
# anyone who finds the port gets the login (or no login)

On top of that, every one of these must require authentication, and the Kubernetes Dashboard's service account must be scoped to the minimum, never cluster-admin. A panel that's both public and unauthenticated, which several of these are by default, is the worst case and the most common one. If you genuinely need remote access, put it behind your VPN or an authenticating reverse proxy, not a raw exposed port.

Whether one of these control planes answers from the open internet is something a stranger finds by probing the known paths and fingerprinting the response, and that's the check we run. SurfaceCheckr probes for these panels from outside, requires all the content signatures to match before it calls it a hit, not just a bare 200, so you don't get a false alarm from a page that merely mentions the product, and flags the ones that are reachable. We see that the panel is exposed; we don't log in, send any action, or test whether auth is weak, because we stay passive. Knowing the orchestrator for your whole stack is sitting on a public port is the finding. Moving it behind your network is the fix, and it's usually faster than the breach would be to clean up.