The presentation discusses container security and vulnerabilities in the Kata container runtime. The main thesis is that containers are only as secure as their configuration and that dropping unused privileges and applying best practices can improve container security.
- Containers are only as secure as their configuration
- Dropping unused privileges can improve container security
- Best practices like username spaces can mitigate vulnerabilities
- Sandboxes are not a replacement for other security features
- Kata container runtime vulnerabilities can be exploited to break out of the sandbox
- The presentation focuses on a single container guest under Docker
The presenter explains that the goal is to escape the container and break out of the virtual machine. They emphasize that the vulnerabilities shown are not an indictment against Kata, but rather an opportunity to learn about container security.
Containers offer speed, performance, and portability, but do they actually contain? While they try their best, the shared kernel is a disturbing attack surface: a mere kernel vulnerability may allow containerized processes to escape and compromise the host. This issue prompted a new wave of sandboxing tools that use either unikernels, lightweight VMs or userspace-kernels to separate the host OS from the container's OS.One of these solutions is Kata Containers, a container runtime that spawns each container inside a lightweight VM, and can function as the underlying runtime in Docker and Kubernetes. Kata's virtualized containers provide two layers of isolation: even if an attacker breaks out of the container, he is still confined to the microVM.Several Cloud Service Providers are deploying Kata in production to support customer multitenancy in their Serverless and CaaS offerings. With its focus on isolation, does Kata Containers actually contain? In this talk, we'll put Kata's isolation to the test, and attempt to escape the container, break out of the encapsulating VM, and finally, compromise the host.