Attacking a Cluster

One compromised pod, then the node under it, then every secret in the cluster.

25 minkubernetesprivilege-escalationcontainer-escapeexploitation

What you will learn

-Chain a pod foothold into node-level code execution
-Abuse create-pod rights to mount the host filesystem
-Turn stolen node credentials into cluster-wide access

You have in a . Maybe an got you there, maybe a vulnerable web app, maybe a supply-chain package. It does not matter how you arrived. What matters is the climb: pod to to . Each step trades a small foothold for a bigger one, and the cluster's own features do most of the lifting.

Step one: know your surroundings

Before any , answer three questions. What do you hold, from the last two lessons. Are you privileged. And can you see the .

assess the pod you landed in

# root inside the container plus a fat capability set is a strong start

$id; capsh --print 2>/dev/null

# confirm you are containerized and look for host mounts

$cat /proc/1/cgroup; ls -la /

# API server host and port, service ports, sometimes leaked creds

$env | grep -i kube

# a mounted docker.sock or host path is a direct escape

$mount | grep -E 'docker|containerd|host'

If you see /var/run/docker.sock mounted, or the pod runs privileged, you can escape to the node right now. If not, is your ladder.

Step two: create a pod that mounts the host

This is the workhorse escalation. If your token can create pods, you do not need a bug. You ask politely to schedule a pod that mounts the node's filesystem, then you read whatever you want from the host.

Apply it, exec in, and you are reading the node's disk as if you were sitting on the box.

deploy the host-mount pod and read the node

# schedule the pod; nodeName can pin it to a specific node if you want

$kubectl apply -f evil-pod.yaml

# chroot into the node's real filesystem

$kubectl exec -it maint-check -- chroot /host bash

# kubelet and admin kubeconfigs live here on many setups

$cat /host/etc/kubernetes/*.conf

The type: Directory and a sleep keep it stable. Pin it with nodeName if you are hunting a specific node's .

Step three: harvest the node, reach the cluster

Once you are on the node filesystem, the loot is concentrated in a few places. Every pod scheduled on this node has its token sitting under the 's pod . The kubelet's own kubeconfig can talk to the . And if this is a -plane node, etcd and the admin kubeconfig are right there.

collect credentials from the node

# service account tokens for every pod on this node

$find /host/var/lib/kubelet/pods -name token 2>/dev/null

# the kubelet's credential, often more privileged than your original token

$cat /host/var/lib/kubelet/kubeconfig

# on a control-plane node, the cluster CA and client certs

$ls /host/etc/kubernetes/pki 2>/dev/null

Collect tokens, replay them with kubectl --token=, and check each with auth can-i --list. One of them usually reaches further than the last. That is the pivot: a token from a sensitive pod that can read secrets cluster-wide, or an admin kubeconfig that ends the engagement.

Grab kube-system service accounts

The tokens worth stealing belong to pods in kube-: controllers, CNI agents, cloud provider integrations. They are often bound to broad ClusterRoles because they legitimately need them. Find a node running one, host-mount it, lift the token, and you frequently inherit cluster-admin-adjacent rights without touching an actual admin .

Authorized targets only

Host-mount escapes and token harvesting are full compromise techniques. Run them only on clusters you own or have explicit written to test, such as Kubernetes Goat or a scoped engagement. This activity is loud in and illegal without permission.

Your token cannot read secrets, but auth can-i shows you can create pods. Why does that still lead to the secrets?

Exercise

You harvested a token file from /host/var/lib/kubelet/pods and want to see how far it reaches before using it. Write the kubectl command that lists that stolen token's full permission set.

Common Cluster Misconfigurations Hardening a Cluster