Cloud Native Computing Foundation Cloud Native eBPF Day North America 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Generating seccomp policies with eBPF - Marga Manterola, Microsoft

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Generating seccomp policies with eBPF - Marga Manterola, Microsoft

Seccomp is one of the security mechanisms that can be used in Kubernetes to restrict the system calls that a process running inside a container can execute. In order to use it, the user must define a seccomp profile with the list of allowed system calls. In many cases it’s not very easy to understand what the system calls a process could require are, especially if the user deploying the application is not its developer.
In this lightning talk Marga will present the Seccomp Policy Advisor, an eBPF-based tool that captures all the syscalls that a pod executes to suggest a seccomp profile. Marga will present a demonstration of this tool and will cover its implementation briefly and shows how it integrates with the Kubernetes Security Profiles Operator.

A

Hi, I'm margaret monterella, a principal engineering manager at microsoft, leading a team that develops ebpf tools for kubernetes. The main project in my team is inspector gashet, which I'll use for today's demo. There are already a bunch of talks out there about inspector gashed, so I won't go into details here. I should say that it's a collection of gadgets that help us get insights on.

A

What's going on in our kubernetes clusters, using the power of evpf tools, the gadget that I will be demonstrating uses secomp setcomp is one of the security mechanisms that can be used in kubernetes. To restrict the system calls that a process running inside a container can execute to use it. We must define a second profile listing each of the system calls aloud, but it's not easy to understand what system calls our processes could require. If we list too few, our workload may end up not running.

A

If we list too many, we might be leaving a door open to possible attacks to help users facing this issue. We created a second policy advisor gadget. It's an evpf-based tool that can be used to capture all the that. A pod executes and then generate the corresponding second profile, not only that it can also integrate with the kubernetes security profiles operator directly. Creating the needed resources see it in action.

A

For this demo, I will be using a python app that uses flask and uwsgi.

A

Let's first try to apply it, as is to check that it works.

A

All right this was created.

A

B

Let's query the service uncurl, it.

A

All right, we have a working demo service. Now, let's see how we can use inspector gadget to generate the necessary second policy to do that, we will use this trace resource that specifies the node, the pod name and the name space that we want to trace, and for now it says that the output mode is status, which means that the generated second policy will be stored in the status of this same trace resource. So let's apply this.

A

Okay, so we have the resource created to start tracing. We need to annotate it with a start operation right, so this is now tracing and if we curl our service again, this cisco will get caught by our gadget and if we now, instead of start, we say generate.

A

It should have generated the second policy and it's stored in the status. So let's look at that.

A

So if we go here to the status, we see that the policy is there. The default action is er, no, which means that if a cisco is executed that it's not in the list of allowed options, it will fail with an error, and we can see that the list here is not too long.

A

That's because we just had like a single request handled by this calls. uh Let's look at the policy that we would generate for a different action.

A

What happens, for example, if I try to execute the bash command inside the container, to do that, we need to first stop the current trace and start a new one. So, let's.

B

Do stop and start and.

A

Now we will do exact bash and we can list the files and that's it, and now we can call generate again.

B

And we can look at the.

A

A

So here's the status- and we see that it's quite a few more syscalls, and these were the ciscos that were needed to execute bash and then to execute ls inside that brush all right. So in these two cases I have captured the ciscos necessary for doing just one action for a second policy to work. It needs to include not only the desired workloads, but also the calls used while bringing up the pod to do that. We need to stay start the trace before creating the pod, we'll delete our resources to start fresh.

A

Now, let's stop the trace and start it again.

A

And now, let's create the workload.

B

All right and let's get the service.

B

A

Okay, this is working fine and we can now generate the policy again now that we have captured the start of the part and the request.

B

Now, let's look at the generated policy.

A

Okay- and we see that it includes quite a few syscalls- those are all the calls necessary to start the pod and then handle our request. Of course, if this was like a proper uh pod, we would generate a lot more workload than this, but that's what we have for the demo. Now we see how we can generate the policies, but we don't want to be copying and pasting any of these. So what we will use now is the integration with the kubernetes security profiles operator.

A

Our cluster already has the security profiles operator running. We can look at this. There are a couple of pots there and we can also look at the profiles that.

A

Come with the operator now, what we want is to generate another second profile like this, for our workload. To do that, we will edit this trace second ammo and in the output mode instead of status, we will say external resource.

A

A

We will put the the namespace and the name of the resource.

A

All right now, let's apply this.

A

And call generate again.

A

And when we release the profiles, once again, we see that our generated profile is there now to use this, we need to modify our yaml file.

A

And here where it says unconfined, we need to change this to localhost.

A

And then in localhost profile.

A

We need to say operator gadget generated policy.json.

A

We need to delete the workload and apply it again.

A

It is still working.

A

Yeah works fine, but what about the washer that we sell before.

A

Oops operation not permitted, this got blocked because it's using syscalls that were not present in the profile that we generated, and this is actually something that we wanted. What about python.

A

Nope also blocked all right and that's it for today's demo. Now I have to say that this gadget is quite new, it's mostly experimental for now, but even if it's not really polished, it already shows how we can use ebpf to help kubernetes operators that want to use segcomp in their clusters.

A

Thanks for watching.