Nodes

Shared nodes are a standard part of the Kubernetes promise, and where a lot of the resource and cost savings come from. By default this uses containerd/CRI-O style containers, which share a Linux kernel and have a “flexible” security model. There are two main areas where this can present risks of container breakout, and then a couple of other things to consider once tenants are sharing a node.

Increased pod rights

If tenants have the ability to influence the configuration of their pods, either directly or indirectly, they can just remove the isolation provided by the container. Setting privileged: true, mounting the node’s filesystem with a hostPath volume, or sharing the host’s PID or network namespaces will all get you onto the underlying node pretty easily.

The usual way of stopping this is admission control, with something like Pod Security Admission enforcing the baseline or restricted Pod Security Standards. It’s worth remembering the “indirectly” part though. A tenant who can relabel their namespace can switch Pod Security Admission off for themselves, and bugs like CVE-2026-2270 let a tenant create pods in namespaces that don’t have an enforce label at all.

Shared kernel exploits

The shared Linux kernel is a large attack surface and has always been a source of security concerns in containerized systems, as a successful attack on it can allow for breakout to the underlying host.

Where this has changed recently is the cost and ease of acquiring a container breakout exploit. What might previously have cost thousands of pounds can now be relatively easily created with a Local Privilege Escalation CVE, an LLM and a small amount of time and money.

As an example, when CVE-2026-46243 (CIFSwitch) was published along with a local root PoC, I gave an LLM the write-up and the PoC, plus a microVM it could use to build and test exploits, and asked it to try for a container breakout. About two hours and roughly $13 of tokens later it had a working one. There’s more detail in Do containers still contain?

None of this is a new class of problem. Kernel LPEs were always potential container breakouts, it’s just that turning one into a working exploit used to need skills that not many people had. Given the rate at which Linux kernel issues are being discovered and the ease of exploitation, depending solely on container isolation is likely to be a risky prospect. Where tenants don’t trust each other, sandboxed runtimes like gVisor or VM-based isolation like Kata Containers are worth a look.

Shared node services

Once someone is on a node, it’s not just the other tenants’ containers they need to worry about. Each node has its own credentials for the kubelet and kube-proxy, and the cluster’s DaemonSets run a pod on every node, often with quite powerful service account tokens (see the operators page).

Even with the Node Authorizer and NodeRestriction admission plugin doing their jobs, a compromised node keeps a fair amount of visibility across the cluster. The Atredis assessment of Salesforce’s shared control plane model found that a node could still list pods, services and nodes across every namespace, and create events tied to any object, including ones belonging to other tenants.

Noisy neighbours

Lastly there’s the classic noisy neighbour problem. Tenants on the same node are sharing CPU, memory, disk and network, so without resource requests and limits (and quotas to make sure they’re set), one tenant can make life pretty miserable for everyone else on that node.