 Yes. So, hello, everyone. I'm Mikhail Dostetsky, and I would like to talk about the project Loxy, which is trying to contain the containers which do not contain. Before I dig into the project a bit about myself, I'm Mikhail Dostetsky. My nickname in open source communities is Vadorovsky. I'm a software engineer at DeepFence, and nowadays I rewrite mostly in Rust, and it became my favorite language, although I have a huge background in Go, C, and Python. What? Oh, really? Oh, okay. I apologize for that. So, yeah, that was the first slide. This was about me. And, yeah, here on this collocated event we talk about container security, the fact that we have this collocated event proves so much how this space is emerging and how much good progress we have here. Although I must say that the most of initiatives and most of projects in Kubernetes about security are focusing either on securing Kubernetes API or finding vulnerabilities in images. And the project I'm going to talk about is trying to cover the other area. It's trying to cover container runtimes and everything which is closer to the Linux kernel and try to enforce security policies there. And it also aims to do it in container runtime agnostic and container engine agnostic way in the long term. You've probably heard a lot about EBPF either on KubeCon or Kubernetes-related conference, but to briefly describe it, it's a technology coming from the Linux kernel which allows to run sandbox programs inside the Linux kernel. And those programs are triggered by various events. It can be the event of calling a kernel function, it can be an event related to incoming network packet in the system. And EBPF is event-driven, so EBPF allows you to write programs which are triggered by specific kernel event which gets the context of that event and does something with it. And EBPF has many years it's widely adopted. There is the most known project called CIVIUM, which is using it with great success for networking, for Kubernetes networking. There are also several projects, for example, Project Valko which is leveraging it for observing potentially malicious behavior in the system. Although there are many security projects which already use EBPF for observing the events and malicious behavior, the question is whether EBPF could be used also for preventing such behavior and actually enforcing policies and cutting off the attacker from the containers. And before I come with straightforward answer to that question, I will explain another concept in the Linux kernel, which is called LSM, which stands for Linux security modules. And most of you probably know the two popular security systems in Linux. One is S-Linux, the other is UpArmor. And both of them are built on top LSM. And LSM is an API in the kernel, which provides various hooks inside the Linux kernel, which lets programmers, which let developers of security systems, decide whether some particular action is allowed to happen. And huge examples of LSM hooks are, there is a LSM hook for opening a file. So, for example, S-Linux or UpArmor are triggered by the event when you are opening some file in the operating system. It's getting the data of what the file is, who is initiating that file opening action. And based on that, security systems are making a decision whether it looks safe to them or whether it's a malicious behavior and they want to deny it. And, well, for the most of time, development of Linux security modules involved either writing your kernel module, which would have to be loads with LSM for example, or contributing to the Linux kernel source tree. And S-Linux and UpArmor actually have kernel modules inside the upstream kernel source code. So they are developed together with the Linux kernel. Developers, patches of S-Linux and UpArmor developers are eventually ending up in the storehouse review and Linux kernel tree. But that was for the majority of time, although since kernel 5.7, there is a new type of BPF programs which actually can leverage LSM hooks. So nowadays, there is no need anymore for writing kernel modules or modifying the kernel source code. Nowadays, you can write your external BPF program which is attaching to LSM hooks and write your own policy engine that way. And you can just load it when you are a real-to-user in the system and you have your own LSM BPF programs. You can just load them and they work on the kernel. If the kernel is recent enough. And that technology is used by Loxy. And Loxy is the project which is trying to use BPF LSM to make containers more secure, to make containers harder. And Loxy is also using the other thing, the other exciting technology related to BPF. It's using AIA. And AIA is Rust Library which lets you write BPF programs purely in Rust. Both BPF part and TSM space part. There is no coding in C needed and there is no need to use BPF. Everything is done in pure Rust. And everything you need to build BPF programs with AIA is just having cargo and Rust nightly on your machine. So that's pretty cool, I think. And Loxy is aiming to secure containers and it's doing so by detecting crancy processes, tracking their children and forcing policies on them. And for now, the approach which Loxy took with implementing policies is that it comes with free predefined policies inspired by say, post-security admission controller in absolute Kubernetes. So these are restricted baseline policies which are meant for regular applications running in Kubernetes cluster and the privileged one where everything is allowed and that privileged policy is meant mostly for, let's say, the part of infrastructure, CNI plugins, service meshes or anything which needs to do something more than regular containers should be allowed to do inside the Kubernetes cluster. And to briefly step-by-step describe Loxy works is that there is one BPF program and there is FA notify mechanism which is tracking new run C processes. So when a new run C create and run C start process comes in in the system on the Kubernetes node or on the node where we are using Docker, then Loxy is being aware of that and it's getting the container ID and PID of the transparency process which is starting and based on that it's trying to figure out whether what's the context of that container, whether it's running in Docker or whether it's running in Kubernetes. If it's running in Kubernetes, it's trying to figure out the policy which should be applied there and after figuring that out, it's saving the information about the initial process, run C process and container and policy level into BPF maps. And afterwards there are other LSM BPF programs which based on that when there is LSM hook triggered in the system, they are firstly checking whether the given process is containerized and if it's containerized then it's applying policies according to logic which is present in Loxy code base. And for now Loxy is able to enforce policies on byte mounts so it's able to prevent baseline and restricted containers from binding, from bind mounting anything from the host file system. It also is able to restrict some potentially, some directories from being accessed which can potentially leak some information about the host because for example like there is Sysfs and directory inside containers which has identical content with the host file system. So the goal of Loxy is for every such unnames based directory which can potentially leak information from the host, Loxy is trying to hide them. Loxy is also preventing the access to kernel Syslog because on many container runtimes and many Kubernetes clusters you are able to execute the Dmesk inside container and Loxy is also coming with the policies about user ID so it prevents from logging S-root. This is how the policy level can be applied on Kubernetes and the future plan for Loxy is to allow executing only specific binaries in the end every point for example there is a plan for making the most of container file system read only immutable. The plan is to support more container runtimes because for now only in the runs he is supported and more container engines. We also plan to leverage a BPF LSM attached to C groups and maybe also a good plan would be to develop Loxy in the direction of providing a policy language. Do I have some time for a small demo yet or not really? All right. Okay. So here I have a Kubernetes cluster with which is running Loxy. So we can get what's of it and for now it's just an empty K-3s cluster. Let's try to look for Loxy-Lox in the separate terminal here. For that we can use Journal, CTL, a few Loxy and here are the locks. I prepared two types of deployments. So there is one deployment with EngineX which should fail and that's because it's using the default container image of EngineX which is running as root and by default Loxy is enforcing a good practice of logging as a regular user inside containers not running regular applications as a root. So when we try to deploy it, Loxy should prevent it from running and let's see whether that works. Yeah, it's crashing but also there is another EngineX should succeed which is based on Bitnami image with regular user running and it's succeeding. Thank you for listening. I invite you to check our documentation which is on Loxyprojectgithub.io. We have a GitHub repository where you can check out the code and the discussion about the project is taking place on Rust Cloud native Discord server where we have a dedicated channel for the project. Thank you very much for listening.