CoursesKubernetes attack & defenseControl plane & operators

Node & kubelet security

Pod→node blast radius, isolation, metadata blocking.

Advanced30 min · lesson 11 of 15

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.

isolate sensitive workloads onto their own nodes
# 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:NoSchedule
spec:
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.

Defending the pod → node → cluster path
1pod compromiseRCE in a container2escapeblocked/detectedadmission + runtime rules3node isolationsensitive tiers on…4containedblast radiusnot the whole cluster
A node hosts many identities. Block the escape, detect it if it happens, and isolate sensitive workloads so one escape is not cluster-wide.
Block pod access to the cloud metadata endpoint
A compromised pod that can reach 169.254.169.254 may retrieve the node’s cloud IAM credentials, pivoting from container to full cloud access. Restrict metadata access (network policy, IMDSv2 with a hop limit, or the platform’s metadata-blocking setting) so a container breakout does not become a cloud-account breach.