 Hi, I'm Marga Manterella, a principal engineering manager at Microsoft, leading a team that develops EVPF 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 Gashet, so I won't go into details here. I just say that it's a collection of gadgets that help us get insights on what's going on in our Kubernetes clusters, using the power of EVPF tools. The Gashet that I will be demonstrating uses SecComp. 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. To use it, we must define a SecComp profile, listing each of the system calls allowed. 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. If we list too many, we might be leaving a door open to possible attacks. To help users facing this issue, we created a SecComp policy advisor gadget. It's an EVPF-based tool that can be used to capture all the system calls that a pod executes and then generate the corresponding SecComp profile. Not only that, it can also integrate with the Kubernetes security profiles operator, directly creating the needed resources. Let's see it in action. For this demo, I will be using a Python app that uses Flask and UWSCI. Let's first try to apply it as is to check that it works. All right, this was created. It's running. Let's query the service. And curl it. All right, we have a working demo service. Now, let's see how we can use the inspector gadget to generate the necessary SecComp policy. To do that, we will use this trace resource that specifies the node, the pod name and the namespace that we want to trace. And for now, it says that the output mode is status, which means that the generated SecComp policy will be stored in the status of this same trace resource. So let's apply this. 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 syscall will get caught by our gadget. And if we now, instead of start, we say generate, it should have generated the SecComp policy and it's stored in the status. So let's look at that. So if we go here to the status, we see that the policy is there. The default action is Erno, which means that if a syscall 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. That's because we just had like a single request handled by these calls. Let's look at the policy that we would generate for a different action. 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 the new one. So let's do stop and start. And now we will do exec bash. And we can list the files. That's it. And now we can call generate again. And we can look at the status. So here's the status and we see that it's quite a few more syscalls and these were the syscalls that were needed to execute bash and then to execute ls inside that bash. All right. So in these two cases, I have captured the syscalls 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 start the trace before creating the pod. We'll delete our resources to start fresh. Now let's stop the trace and start it again. And now let's create the workload. Right. And let's get the service and curl it. Okay. This is working fine. And we can now generate the policy again. Now that we have captured the start of the pod and the request. Let's look at the generated policy. 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 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. Our cluster already has the security profiles operator running. We can look at this. There are a couple of pods there. And we can also look at the profiles that 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 the trace second demo and in the output mode, instead of status, we will say external resource and in output, we will put the namespace and the name of the resource. Now, let's apply this and call generate again. And when we list the profiles once again, we see that our generated profile is there. Now, to use this, we need to modify our YAML file. And here where it says unconfined, we need to change this to localhost and then in localhost profile, we need to say operator gadget generated policy.json. We need to delete the workload and apply it again. It is still working. Works fine. But what about the vashal that we saw before? 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? 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 EVPF to help Kubernetes operators that want to use SecComp in their clusters. Thanks for watching.