Node & kubelet security
Pod→node blast radius, isolation, metadata blocking.
Nodes are where containers actually run, and node-level security decides how far a container compromise can spread. Because every pod on a node shares that node’s kernel and its kubelet, node hardening is inseparable from cluster security.
The node as a blast-radius boundary
When an attacker breaks out of a container to the node — via a privileged pod, a hostPath mount, or a runtime/kernel bug — they gain access to every other pod scheduled there, including all of their mounted service-account tokens and secrets. That is why admission control (blocking privileged/hostPath pods) and runtime detection matter so much: they defend the pod-to-node boundary. For genuinely sensitive workloads, node isolation — dedicated node pools with taints, or a stronger sandbox like gVisor/Kata for untrusted tenants — limits which workloads share a kernel and shrinks the blast radius of any single escape.
# Dedicate nodes to a sensitive tier so a compromise elsewhere cannot# co-locate onto them. Taint the nodes, tolerate + select in the workload.kubectl taint nodes secure-pool-1 tier=payments:NoSchedulespec:nodeSelector: { tier: payments }tolerations:- { key: tier, operator: Equal, value: payments, effect: NoSchedule }# + PSA restricted, dropped caps, no hostPath — so nothing here can reach the node.
Harden the node itself
Beyond isolation, harden each node: keep the host kernel and container runtime patched (container escapes exploit runtime and kernel bugs, and the kernel is shared by every container), minimize what runs on the host, and lock down the kubelet as covered earlier. Block pods from reaching the cloud metadata endpoint so a compromised container cannot lift the node’s cloud credentials. Node security ties the whole course together: admission stops the dangerous pods, runtime detection watches for escapes, and node isolation ensures that even a successful escape is contained to a limited set of workloads rather than the entire cluster.