Cloud Native Computing Foundation Cloud Native eBPF Day EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Armoring Cloud Native Workloads with BPF LSM - Barun Acharya, Accuknox

Description

Lightning Talk: Armoring Cloud Native Workloads with BPF LSM - Barun Acharya, Accuknox

Cloud Native Workloads are not protected by default as the various tools for security into place provides perimeter security at the host, or the network and not necessarily the workload itself. BPF LSM provides with security hooks necessary to set up least permissive perimeter for various workloads. KubeArmor is a cloud-native runtime security enforcement system that leverages various LSMs to secure the workloads. There’s a need for a declarative policy management system for Mandatory Access Control in modern workloads where underlying infrastructure is abstracted away. This talk will be about how BPF LSM provides fine grained control over security hooks and how KubeArmor leverages these LSM superpowers to abstract away the complexities. How BPF LSM compares with other LSMs to protect modern workloads and what design considerations/challenges for integrating BPF LSM in KubeArmor.

A

Hello: everyone thank you for joining me on my session on armoring cloud native workloads with bpflsn, I'm varun acharya, a software engineering intern at acunox.

A

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 lock, 4g and pawn kit, there's an ever more demanding need to enforce runtime security.

A

So what existing mitigation mechanisms do we have for enforcing run time security? We have linux security modules, lsms like app armor, sc linux, land lock. These are mature ecosystem of hooks to enforce various security models. Lsms handle time of check and time of use problem very well.

A

Then we have second secure computing which helps in sandboxing by restricting actions available to the containers.

A

Lsms and secomp are linux kernel features, but we can mitigate these using user space techniques as well like using ld preload, 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.

A

There's a steep learning curve associated with the policy language of lsms. Different versions of lsms behave very differently. For example, s linux treats everything inside a container as a single entity.

A

Dynamic enforcement is not possible for secure computing limited. 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 cisco's without going through the dynamic library at all, such as anything written in go, doesn't use, lipstick, dynamic library and calls the kernel directly enter port security context.

A

A security context defines privilege and access control settings for a pod or a container security contact settings include, but are not limited to sec. Comp capabilities, app, armor s, linux, port security context helps solve some of the problem, especially integrating traditional mitigation systems with the modern cades infrastructure, but we still need to learn the policy language for various primitives and team differences in behavior. Accordingly, suppose we have a cluster spanning multiple nodes, a few supporting app armor and a few supporting sl linux.

A

We will need policies for both of them and tame the differences behavior accordingly enter vpflsm bpflsn combines the power of the lsm framework, which provides with necessary hooks for inline security enforcement, with the flexibility and observability powers of ebpf to help secure and modern cloud native workloads more efficiently, let's venture how these power can be utilized.

A

Today, we very recently had a vulnerability known as pawn kit in which an unprivileged user could gain root privileges, mitigations involved, removing sui debit from exploitable binaries or updating the systems with patched packages, but denis here created a simple bpf lsm program which hooks on to bprm check security and blocks execution of any process with rxc equal to zero, which solves the root problem of the vulnerability.

A

But what, if you need your program to have arcs equal to zero? You can tweak the bpf lsm program to exclude your cloud native workload or limit the bpa program to unprivileged users. Only that's where bpf lsm shines. You have the flexibility to tweak it according to your needs.

A

Let's look at another project, kimc lock, which is part of the bpf 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 bpf.

A

So ironically, this project re-implemented a subset of features, leveraging bpf lsm, while still preserving the ability to leverage other lsms for security enforcement in other parts.

A

Ebpf has changed the game for observability and monitoring with bpf lsm. We can hook on to strategically better place points in the kernel and can help us avoid vulnerabilities, exploiting time of check and time of views like we can see in this figure a bpf hook on 6x8 we may or may not know. If there was a malware executed or not, but the lsm pro would definitely not. This was covered in much better way last year by kp and leonardo, when they introduced bpf lsm to us on this stage.

A

So to summarize how we can leverage bpflsm today is virtual patching a quick program to prevent an 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 parameter tailored for our own workload.

A

We can gain more observability at points better located than just tracing cisco, since lsm hooks are strategically placed in the current, but is this enough to protect our workloads? Did we address all the pain points we pointed out in the beginning?

A

The things we saw, bpf 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, syscall and lsm hooks to help armor apart cloud native workloads.

A

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 asset linux 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 lsm's, with the flexibility that bpf lsm brings. We are positive about integrating it into the cube armor to build a cloud native runtime security enforcement engine. You can track artwork at the link mentioned here.

A

I would like to end this on the note. Bpf lsm could possibly change the runtime security landscape for application security. Just the way evp have changed it for network security.

A