In this lesson, you will learn how to use Seccomp (Secure Computing mode) to restrict the specific system calls a container can execute on your host kernel.
Understanding Seccomp
By default, a container shares the host's Linux kernel. While this makes containers lightweight, it also means a compromised container could potentially exploit the kernel using system calls (syscalls)—the primary interface between user-space applications and the kernel.
Seccomp acts as a security filter that sits between the container and the kernel. By applying a Seccomp profile, you define a "whitelist" of allowed syscalls. If a process inside the container attempts to trigger a syscall not on that list, the kernel will block it—typically by killing the process or returning an error.
Implementing a Profile
A Seccomp profile is simply a JSON file that lists the permitted syscalls. You can define a custom policy for your application’s specific needs. For example, if your application doesn't need to mount filesystems or change file permissions, you can explicitly forbid syscalls like mount or chmod.
In Kubernetes, you apply these profiles at the Pod or container level using the securityContext:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/my-secure-profile.json
When you set the type to Localhost, Kubernetes looks for a file stored in the Kubelet's default Seccomp directory on the worker node. Alternatively, you can use the RuntimeDefault type, which applies a sane, pre-configured set of syscall restrictions provided by your container runtime.
Why this matters
Applying the principle of least privilege at the syscall level provides an essential layer of defense-in-depth. Even if an attacker gains shell access to your container, they are severely restricted because they cannot execute sensitive operations like modifying kernel parameters or interacting with hardware directly, significantly reducing the blast radius of a potential container breakout.
Key Takeaway: Seccomp enforces the principle of least privilege by strictly limiting the syscalls a container can make, preventing malicious processes from interacting with the host kernel in unauthorized ways.