 Hello everyone! Thank you for joining me on my session on Armoring Cloud Native Workloads with BPFLSM. I am Bharunacharya, a software engineering intern at AQNOS. Let's first talk about the need to armor up your workloads. With the rise of adoption of modern cloud-native infrastructure, so has risen the cyber attacks on the same. With the rise in recent vulnerabilities, like log4j and Poncat, there's an ever more demanding need to enforce runtime security. So, what existing mitigation mechanisms do we have for enforcing runtime security? We have Linux security modules, LSMs, like AppArmor, SCLinux, Landlock. These are mature ecosystem of hooks to enforce various security modules. LSMs handle time of check and time of use problem very well. Then we have Seccom, Secure Computing, which helps in sandboxing by restricting actions available to the containers. LSMs and Seccom are Linux kernel features, but we can mitigate these using user space techniques as well, like using LTP load. But each of these come with their set of drawbacks, especially in the context of cloud-native workloads. Like, LSMs are not well integrated with the dynamic environment of Kubernetes and Docker. There's a steep learning curve associated with the policy language of LSMs. Different versions of LSMs behave very differently. For example, SCLinux treats everything inside a container as a single entity. Dynamic enforcement is not possible for Secure Computing. There are limited filtering options and filtering cannot work with object reference. For user space controls, there are limited deployment options. Like, you can only override using dynamic libraries, but the attacker can still invoke scouts without going through the dynamic library at all. Such as, anything written in Go doesn't use Lipsy Dynamic Library and calls the kernel directly. Enter port security context. A security context defines privilege and access control settings for a port or a container. Security context settings include but are not limited to Sec Comp, Capabilities, App Armor, SCLinux. Port security context helps solve some of the problems, especially integrating traditional mitigation systems with the modern case infrastructure. But we still need to learn the policy language for various primitives. And tame differences in behavior accordingly. Suppose we have a cluster spanning multiple nodes, a few supporting App Armor and a few supporting SCLinux. We will need policies for both of them and tame the differences behavior accordingly. Enter VPF LSM. VPF LSM combines the power of the LSM framework, which provides with necessary hooks for inline security enforcement with the flexibility and observability powers of EVPF to help secure and modern cloud native workloads more efficiently. Let's venture how these power can be utilized today. We very recently had a vulnerability known as PonKit, in which an unprivileged user could gain root privileges. Mitigations involve removing SUID bit from exploitable binaries or updating the systems with patched packages. But Dennis Air created a simple VPF LSM program, which books onto BPRM check security and blocks execution of any process with AXI equal to 0, which solves the root problem of the vulnerability. But what if you need your program to have AXI equal to 0? You can tweak the VPF LSM program to exclude your cloud native workload or limit the VPF program to unprivileged users only. That's where VPF LSM shines. You have the flexibility to tweak it according to your needs. Let's look at another project, KIMG log, which is part of the VPF log project. Lockdown LSM, which aims to restrict access to the running kernel image and was introduced in the Linux kernel in 5.4. But it is too restrictive and disables some necessary features like VPF. So ironically, this project reimplemented a subset of features leveraging VPF LSM, while still preserving the ability to leverage other relations for security enforcement in other parts. EVPF has changed the game for observability and monitoring. With VPF LSM, we can hook onto strategically better place points in the kernel and can help us avoid vulnerabilities exploiting time of check and time of use. Likewise, we can see in this figure a VPF hook on 6 execs we may or may not know if there was a malware executed or not, but the LSM probe would definitely know. This was covered in much better way last year by KP and Leonardo when they introduced VPF LSM to us on this stage. So to summarize how we can leverage VPF LSM today is virtual patching, a quick program to prevent and exploit or a new vulnerability. We can have security mitigations in place without full-blown policy rules. We can stack with existing LSMs to set up a security perimeter tailored for our own workload. We can gain more observability at points better located than just tracing Cisco since LSM hooks are strategically placed in the kernel. But is this enough to protect our workloads? Did we address all the pain points we pointed out in the beginning? The things we saw VPF LSM is capable is just the beginning and proves that it is capable of much more. But the ecosystem is still nascent and we can build a more holistic tool to enforce runtime security, leveraging informations from orchestrators, container managers, Cisco and LSM hooks to help armor up our cloud native workloads. We at Cube Armor want to solve this problem by combining the LSM superpowers with the metadata of cloud native workloads, simplifying the security enforcement. Cube Armor already integrates with app armor and SLNs to help secure our cloud native workloads, translating declarative simplified policies to complex LSM rules. But we have had difficulties taming the differences in behavior of various LSMs. With the flexibility that VPF LSM brings, we are very positive about integrating it into the Cube Armor to build a cloud native runtime security enforcement engine. You can track our work at the link mentioned here. I would like to end this on the note, VPF LSM could possibly change the runtime security landscape for application security just the way EVPF changed it for network security. Thank you.