Kubernetes cluster exposed

A Kubernetes cluster doesn’t have one exposed surface — it has several, each independently a path to owning everything. That’s what makes cluster security different from a single service: you’re not closing one port, you’re accounting for five distinct front doors, any one of which is the whole cluster.

The five doors

The API server (6443). Secured with auth and RBAC it’s meant to be reachable — but an internet-facing API server is a continuous CVE and brute-force target, and if anonymous auth is on with a stray system:unauthenticated binding, it’s open. A misconfigured API server is kubectl for attackers.

The kubelet (10250). Every node runs a kubelet, and its API can exec into pods and read their logs and secrets. Historically it allowed anonymous access (--anonymous-auth=true, --authorization-mode=AlwaysAllow), and clusters still ship that way. An exposed, unauthenticated kubelet is code execution in every pod on that node — no API server involved:

curl -sk https://node:10250/pods            # every pod on the node
# and exec endpoints from there

etcd (2379). The whole cluster in one store, secrets included. No RBAC in front of it — reach it without client-cert auth and you read and write cluster state directly.

The dashboard. The Kubernetes Dashboard, exposed and granted a powerful service account, was behind real-world breaches (famously Tesla’s, where an open dashboard led to cryptomining in their cluster). If you run it, it must be behind auth and never public.

A compromised pod. The one that doesn’t require any exposed control-plane surface. An RCE in a public-facing app, plus a mounted service account token and a flat network, lets an attacker query the API and reach every internal service — lateral movement from a single container. This is the most common real path, and it’s why the workload-side controls matter as much as the control-plane ones.

The escalation chain

These doors connect. The textbook cluster takeover:

1. RCE in an internet-facing pod.
2. Read the mounted service account token.
3. The token’s RBAC allows get secrets (or the pod is on the default SA with too much) → read secrets.
4. Or reach the kubelet / a privileged neighbour pod → node.
5. Node → kubelet credential → more of the cluster.
6. A hostPath or metadata-service reach → cloud credentials → the account.

Every link is one of this cluster’s control pages, which is why they’re a set, not a menu.

Verify it worked

Sweep the doors from outside the cluster:

for port in 6443 10250 2379 2380; do
  nc -zv -w5 your.node $port 2>&1 | tail -1
done

10250, 2379 and 2380 reachable from the internet are all serious findings. Test the kubelet for anonymous access specifically:

curl -sk --connect-timeout 5 https://your.node:10250/pods -o /dev/null -w '%{http_code}\n'

A 200 there is unauthenticated node access — pod exec and secrets, no credential.

Test the API server for anonymous reads:

curl -sk https://your.api:6443/api/v1/secrets -o /dev/null -w '%{http_code}\n'

200 is a total compromise. Check for the dashboard:

kubectl get svc -A | grep -i dashboard

Were you hit? Look for the common attacker artifacts — cryptominers and rogue workloads:

kubectl get pods -A -o wide | grep -iE 'miner|xmrig|kdevtmpfs|coin'
# workloads with suspicious images or high resource requests
kubectl get pods -A -o json | jq -r '.items[] |
  select(.spec.containers[].image | test("^[a-z0-9]+/[a-z0-9]+$") | not) |
  "\(.metadata.namespace)/\(.metadata.name) \(.spec.containers[].image)"' | head

Check for RBAC bindings you didn’t create — the persistence move:

kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | "\(.metadata.name) -> \(.subjects)"'

An admin binding to a service account you don’t recognise is an attacker’s backdoor.

Before you apply this

A cluster with an exposed control-plane surface should be treated as fully compromised — the doors are equivalent to root, and any one being reachable means you can’t assume the others weren’t used.

Response:

1. Cut network access first — firewall 6443/10250/2379 from untrusted sources. Don’t tear down the cluster yet; you need to see what’s running.
2. Enumerate — unexpected pods (miners), unexpected RBAC bindings (backdoors), unexpected service accounts, and anything with a hostPath or privileged you didn’t deploy.
3. Rotate everything. Every Secret in the cluster is potentially read — database passwords, TLS keys, cloud credentials, tokens. And rotate the cloud credentials the nodes’ metadata service exposes, because a hostNetwork or escape reaches them — the breach may have left the cluster for your cloud account.
4. Check the cloud account’s audit log, not just the cluster’s. If node IAM credentials were taken, the real damage may be there.
5. Rebuild. A compromised cluster with node-level access is not something to clean in place — rebuild the nodes, restore workloads from known-good manifests, and bring it up with this checklist applied before it touches a network.

Don’t pay a ransom, and don’t assume a cryptominer is the whole story — miners are noisy and easy to find, which makes them a good cover for the quiet persistence you haven’t found yet.

The durable fix is the whole cluster’s checklist, and the ordering reflects the chain: API server and RBAC close the front doors, network policies and workload hardening break the escalation chain, and etcd plus secret encryption protect the crown jewels.

Related

• Hardening Kubernetes — the full checklist.
• Secure the API server — the most-targeted door.