As the de-facto standard for container orchestration, Kubernetes is extensively adopted by numerous companies and cloud vendors, making its security critical. In this paper, we define a new attack surface called implicit permission: The execution of explicitly granted permissions in Kubernetes dynamically leads to implicit operations on other resources, enabling new permissions beyond the explicitly granted ones. Such implicit permissions create security vulnerabilities that attackers can exploit to compromise an entire cluster.

OS-level virtualization (a.k.a. container) has become a fundamental technology in cloud computing due to the efficiency provided by the shared-kernel design. However, this design results in containers sharing thousands of kernel variables and data structures (termedabstract resources), which are prevalent but under-protected. Without exploiting other kernel vulnerabilities, a non-privileged container can easily exhaust abstract resources to cause DoS attacks against other containers. Even worse, our experiments demonstrate that abstract resource attacks are a broad class of attacks that affect Linux, FreeBSD, Fuchsia, and all shared-kernel container environments on the top four cloud vendors. To defend against the abstract resource attack, we automatically analyze vulnerable abstract resources in the Linux kernel and detect 501 container-exhaustible resources. To confine these abstract resources dynamically, we propose two new techniques: the flexible in-kernel attachment for flexible resource consumption attachment and the tree-based resource accounting for efficient usage retrieval. Based on these two techniques, we design and implement aflexibleabstract resource confinement framework, named Flask, to achieve flexible and efficient abstract resource confinement. Our evaluation shows Flask can efficiently limit abstract resource usage with less than 0.6% performance overhead.

As the dominant container orchestration system, Kubernetes is widely used by many companies and cloud vendors. It runs third-party add-ons and applications (termed third-party apps) on its control plane to manage the whole cluster. The security of these third-party apps is critical to the whole cluster but has not been systematically studied so far.

Due to its faster start-up speed and better resource utilization efficiency, OS-level virtualization has been widely adopted and has become a fundamental technology in cloud computing. Compared to hardware virtualization, OS-level virtualization leverages the shared-kernel design to achieve high efficiency and runs multiple user-space instances (a.k.a., containers) on the shared kernel. However, in this paper, we reveal a new attack surface that is intrinsic to OS-level virtualization, affecting Linux, FreeBSD, and Fuchsia. The root cause is that the shared-kernel design in OS-level virtualization results containers in sharing thousands of kernel variables and data structures directly and indirectly. Without exploiting any kernel vulnerabilities, a non-privileged container can easily exhaust the shared kernel variables and data structure instances to cause DoS attacks against other containers. Compared with the physical resources, these kernel variables or data structure instances (termed abstract resources) are more prevalent but under-protected. To show the importance of confining abstract resources, we conduct abstract resource attacks that target different aspects of the OS kernel. The results show that attacking abstract resources is highly practical and critical. We further conduct a systematic analysis to identify vulnerable abstract resources in the Linux kernel, which successfully detects 1,010 abstract resources and 501 of them can be repeatedly consumed dynamically. We also conduct the attacking experiments in the self-deployed shared-kernel container environments on the top 4 cloud vendors. The results show that all environments are vulnerable to abstract resource attacks. We conclude that containing abstract resources is hard and give out multiple strategies for mitigating the risks.