How to enable Kubernetes container RuntimeDefault seccomp profile for all workloads

NOTE: Kubernetes features that are in alpha aren’t typically available for use by managed Kubernetes services like AKS, EKS, GKE for stability reasons. Please check your providers documentation

All container runtimes ship with a default seccomp profile (or RuntimeDefault) that is applied to containers. These default seccomp profiles aim to strike the balance between a secure set of defaults without sacrificing the functionality of the workload. The problem arrises when these container runtimes are integrated with Kubernetes, Kubernetes will explicitly set the seccomp profile to Unconfined which disables seccomp filtering.

We can easily test that the default seccomp profile is being applied on Docker desktop by running the following commands.

In the output above you can see the following which states that seccomp filtering is enabled at that 60 syscalls are being blocked:

Now that we know all about seccomp profiles and RuntimeDefault let’s take a look at how we can configure Kubernetes to use the RuntimeDefault seccomp profile rather that using Unconfined. First, I would like to demonstrate how a default Kubernetes cluster without this new feature enabled operates. We are going to prove that Kubernetes sets the seccomp profile to Unconfined.

Create a Kubernetes cluster using Kind.

Let’s again run the same test as we did in the previous section but this time on the Kubernetes cluster.

In the output above you can see that seccomp is disabled and that 21 syscalls are being blocked. In comparison with the output of the same test running on Docker on my dev machine using the Docker CLI, seccomp is filtering and 60 syscalls are being blocked. Now that we can see the baseline. Let’s create a cluster with and configure the new RuntimeDefault feature.

Delete the last Kind Kubernetes cluster using the following command:

Now let’s create a new config file called kind-runtimedefault-config.yaml with the following content. You may notice that we are setting the SeccompDefault feature gate to true which enables the new feature:

Create a Kubernetes cluster using Kind and the config file you just created:

Let’s again run the same test however we would expect the RuntimeDefault seccomp profile to be applied.

In the output above you can see that seccomp is filtering and that 61 syscalls are being blocked. This validates that the RuntimeDefault seccomp profile is being successfully applied.

It’s also worth mentioning again that this feature is in alpha so it might be worth waiting for it to mature before enabling it in production.

We covered a lot of ground in this blog starting with seccomp profiles and how they are used in the context of container runtimes. We then enabled a new feature that enables Kubernetes to use the RuntimeDefault seccomp profile. The question now is “How much does this matter?” and that’s something I will leave you to answer. Certainly, anything you can do to reduce the attack surface area on the Linux kernel from a container is an incremental improvement on the overall security posture of the Kubernetes cluster. Let me know what you think?

Related posts:

An improvement in computer system technologies is precisely what the whole world is experiencing now. There was an intense change that has been made with the use of world-wide-web. Even games have…

Setelah berakhir acara trading competition banyak yang bertanya mengapa saldo dummy tiba-tiba hilang, disini kami ingin memberikan informasi bahwa saldo dummy itu hanya bisa digunakan saat Kompetisi…

The special Christmas NFT MANIA QUEST event is starting on December 20th. This is a one-week long fun and adventurous journey where users need to solve tricky riddles and get very nice prizes. The…