T1 privileged pod node escape A pod requesting privileged with hostPID shares the host process namespace and holds all capabilities.
The pod spec is the whole exploit; nothing needs to be vulnerable.
Precondition. Pod Security Admission is not enforcing baseline or restricted on the namespace.
T1 create pods
T1
create pods Privileged, hostPID, hostPath, or hostNetwork pods mount / and chroot to the node for full host access. T0 in kube-system or on a control plane node. Setting spec.nodeName directly places the pod on any node, bypassing the scheduler's taint checks, since taints are enforced by the scheduler only. This is still an ordinary pods create request, not the pods/binding subresource that most admission engines never inspect, so admission policy can see and block it.
↗ Kubernetes documentation kubernetes.io/docs/concepts/security/pod-security-admission/ Privileged pod node escape
T1
Privileged pod node escape Create a pod with privileged + hostPID or hostPath mounting / Set spec.nodeName to a specific control plane node to force placement there. The NoSchedule taint kubeadm puts on those nodes is a scheduler check only, so a directly bound pod needs no toleration chroot or nsenter into the host to gain root on the node Read /etc/kubernetes/pki, steal kubelet cert or SA tokens. This is T0 on the control plane ↗ Kubernetes documentation bishopfox.com/blog/kubernetes-pod-privilege-escalation Break the chain. Enforce the restricted Pod Security Standard on the namespace. That single label removes this hop and several like it.
enter the host namespaces With hostPID and privileged, nsenter against PID 1 gives a root shell in the host mount and network namespaces.
The container boundary is gone at this point, and so is anything RBAC can say about the attacker.
Break the chain. The same restricted Pod Security Standard. Once the pod exists this hop cannot be blocked in-cluster.
harvest tokens from the kubelet directory Under /var/lib/kubelet/pods sit the projected volumes of every pod scheduled to this node, each holding its ServiceAccount token.
A busy node yields tokens for many workloads at once, some far more privileged than the one that got in.
Break the chain. Spread privileged workloads away from general-purpose nodes, and keep token lifetimes short so a harvested token expires quickly.
read the cluster CA private key On a control-plane node /etc/kubernetes/pki/ca.key is readable by root.
It is the key that signs client certificates for the cluster, which makes it the most durable secret there is.
Precondition. Control-plane nodes accept scheduled workloads. Many managed offerings do not expose them at all.
Break the chain. Keep control-plane nodes unschedulable for workloads, and keep the CA on a node no tenant workload can reach.
sign a client certificate offline A certificate the CA signs for a User already bound to cluster-admin authenticates as that user, with no CSR submitted and no approval RBAC needed.
Kubernetes has no CRL for client certificates, so only rotating the CA invalidates it.
Break the chain. Treat CA exposure as requiring a CA rotation, not a permission change. Nothing short of that revokes the certificate.
Sources: kubernetes.io, kubernetes.io