Shared Surface · Nodes
Nodes
Pods from different tenants land on the same nodes and share one Linux kernel. A container breakout — by configuration or through the kernel — collapses the boundary between everything scheduled there.
Shared nodes is a standard part of Kubernetes promise and where a lot of the resource/cost savings come from. By default this uses container/CRI-O style containers which share a Linux kernel and have a “flexible” security model. There’s two main areas where this can present risks of container breakout
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, for example by setting privileged: true in the specification, allowing for breakout to the underlying node.
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 tot he 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.
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.