Project Lightning Talk: Urunc: The New Kid In The Block Of Sandboxed Container... Charalampos Mainas

This talk presents runC, a project designed to enhance container security and performance through stronger isolation mechanisms. The speaker explains that while containers offer speed and ease of use, they often lack the isolation needed in scenarios such as multi-tenancy and AI sandboxing, where traditional virtual machines provide more robust security. runC, a CNCF sandbox project, is a CRI compatible runtime that focuses on single application workloads by utilizing unikernels or single application kernels. The talk elaborates on how runC facilitates the creation of secure sandboxes for untrusted user containers within Kubernetes environments, allowing for dynamic integration of sidecar containers. Performance evaluations demonstrate that runC can significantly outperform other sandbox container runtimes, achieving high pod density and low overhead while maintaining secure execution environments.

Hello everyone. I am Haralambos, but you can just call me Talk into the mic, please. Okay. me Babis for simplicity. And I'm one of the creators and maintainers of runC, the project I'm going to talk to you about this couple of 5 minutes. So, as we know, the struggle is real. Like we have on one side we like containers because they We like containers because they are

fast, they are easy to use, we have a bunch of ecosystem around it. But on the same time, we don't really trust them some specific scenarios where we care about isolation, like multi-tenancy or for example, AI sandboxing. And in the in this kind of scenarios, we want some stronger isolation, like VM. And when we do that, we lose performance and we lose other kind of stuff. So,

with runC, we aim to solve this kind runC is a CNCF sandbox project. It is a CRI compatible runtime, which means it has seamless integration with the rest of the container ecosystem. And it's focusing on what we call single application workloads in the form of unikernels or single application kernels, which means that we package our application alongside with a kernel where we deploy this workload. And the

context here is that we create a container and inside this container, we create a sandbox. This sandbox can come in the form of a software-based sandbox, think about it like gVisor, or in the form of an actual virtual machine. So, let's see a bit in a in a Kubernetes how that looks so you can better understand exactly the difference between other sandbox container runtimes. So, in a

in a pod deployment, we have this pods, we have the sidecar containers, and we have the user containers. The sidecar containers might containers that we deploy as the platform, while the user containers are containers that we don't trust, we don't know who what they do, and we want to isolate them from the rest of the host and all other containers. And that's what you run C does.

You run C treats the sidecar containers as normal containers while the user containers are treated as untrusted and therefore they have to be isolated in a secure sandbox. This sandbox can be in the form of software based sandbox or in a case of virtual machine and you run C sets up this containerized environment for that particular monitor. We call the sandbox monitor as monitor and inside this

sandbox we have the application running as for example in a VM. Think about it as the init being the application. Therefore you run C doesn't have any requirement inside the sandbox for any agent or anything like that. This kind of model has proven quite promising. We have done some evaluation over the years and we have seen for example in the cold boot scenario that if we have

run C with normal containers as a baseline we see that other kind of sandbox container runtimes they can boot they can add an overhead of two times. While in the case of you run C we have an overhead of around 20% or 28% depending on which kind of guest and monitor we going to use. Also we have done a density test in a Raspberry Pi with 8

gigabytes of RAM and we try to deploy as many pods as possible. With run C we managed to reach 467 pods. We can do much more with run C. In the case of G visor we limited to 170. In the case of Kata we didn't get over 30 two. But with you run C we were able to run as many as 430 pods. All of them they

are sandboxed and depending on the again on the on the monitor and the guest we have the number might range there. This little guy 130 is because of QEMU and Linux. So as you can imagine the use cases for this kind of project would be scenarios where we care about fast spawning times and isolation like microservices serverless. Of course, AI sandboxing where we have very minimal specialized

isolation for specific tasks for from AI agents. Um and also as you saw for resource constrained environments where we want to have sandboxed environment sandboxed execution environments for specific workloads. And of course also for CI and CD where we want to fast dev environments and for testing the code and stuff. And also we also have support for BSD so you can also run any kind of BSD

workloads there. So that's for runC. We Anyone you see with the shrimp around in KubeCon we will be all day there. Come and talk to us. We can explain in more details about runC. We will also be in the project pavilion on Wednesday between 10:00 and 1:30 in the morning. The kiosk number is 24B so please come along. You can also join our community. We have community

meetings every last Wednesday of month. This Wednesday has been postponed during because of KubeCon so 1st of April come around for the community meeting and you can find more information in our website with documentation and the GitHub repository with more information about the community, the CNCF Slack workspace and the channel and everything. So thank you for your time. Awesome. Thank you.