What Is Seccomp Profiles? Security Definition
Also known as: seccomp, seccomp profiles, kubernetes security, container security, CKS exam
On This Page
Quick Definition
Seccomp profiles are like a list of approved actions for a computer program. They tell the operating system which low-level operations the program is allowed to perform and which ones are blocked. This helps prevent attackers from using harmful system calls even if they get inside the container.
Must Know for Exams
The Certified Kubernetes Security Specialist (CKS) exam tests seccomp profiles directly and thoroughly. The exam blueprint includes a section on Runtime Security, and seccomp is listed alongside AppArmor and Falco as key runtime security tools. In the CKS exam, you are expected to understand how to configure seccomp at the Pod and Container levels, how to choose between the runtime default, Unconfined, and custom profiles, and how to create and apply a custom profile from an audit log.
You must know that seccomp is part of the securityContext in the Pod spec, and that the profile type can be RuntimeDefault, Localhost, or Unconfined. The exam may present a scenario where you need to restrict a pod to only essential system calls, and you must generate a profile by first running the container with an audit profile, then creating an allowlist. The exam also covers the difference between seccomp, AppArmor, and Linux capabilities.
You must know that seccomp filters system calls, AppArmor restricts file paths and network access, and capabilities break root privileges into named units. The exam may ask you to identify which security control would prevent a specific type of attack. For example, if an attacker uses ptrace to attach to another process, seccomp blocking ptrace would stop the attack.
Additionally, the CNCF Cloud Native Security Specialization and the CKS exam both include questions about the default seccomp profile applied by Docker and Kubernetes. You need to know that Kubernetes 1.22+ automatically applies the RuntimeDefault profile if the node supports it.
You also need to understand that seccomp profiles are stored as JSON files on the node and must be available to the kubelet. The exam may give you a partially correct profile JSON and ask you to fix it. Overall, seccomp is a high-weight topic on the CKS exam, and mastery is expected.
Simple Meaning
Imagine you are working in a large office building. Your security badge gives you access to certain floors and rooms, but not to the server room, the CEO's office, or the maintenance tunnels. This restriction keeps the building safer because even if someone steals your badge, they cannot reach the most sensitive areas.
In the world of Linux containers, seccomp profiles work exactly like that badge. Every program running inside a container needs to ask the Linux kernel for permission to do certain things, like opening a file, creating a network connection, or reading from the keyboard. These requests are called system calls.
There are hundreds of different system calls in Linux, and many of them are powerful and dangerous. A seccomp profile is a security filter that sits between the container and the kernel. It checks each system call against a rules list.
If the call is allowed, it passes through. If it is not allowed, the kernel blocks it and the program either gets an error or crashes safely. By default, Docker and Kubernetes apply a default seccomp profile that blocks around 44 of the most dangerous system calls, such as those that can modify kernel settings, load kernel modules, or access raw hardware.
You can also create custom profiles that are even more restrictive, allowing only the exact calls your application needs. This is a core security practice for hardening containers, especially in multi-tenant environments or when running untrusted code. Without seccomp, every container would have access to the full power of the Linux kernel, which is like giving every employee a master key to the entire building.
Full Technical Definition
Seccomp, short for secure computing mode, is a Linux kernel feature introduced in kernel version 2.6.12. It allows a process to switch into a secure state where it can make only a restricted set of system calls, such as read, write, exit, and sigreturn.
If the process attempts any other system call, the kernel either kills the process with a SIGKILL or returns an error, depending on the mode. Seccomp profiles extend this basic mechanism into a filtering system using Berkeley Packet Filter (BPF) rules. In modern Docker and Kubernetes environments, seccomp works in mode 2, also called seccomp-bpf, which allows administrators to define custom allowlists or denylists of system calls.
A seccomp profile is a JSON file that defines a set of rules. The profile can specify default actions, such as SCMP_ACT_ALLOW, SCMP_ACT_ERRNO, or SCMP_ACT_KILL, and then list specific system calls with their own actions. For example, a profile might default to killing the process on any disallowed call, but explicitly allow calls like accept, bind, connect, open, read, write, and close.
The profile is loaded into the kernel when the container runtime starts the container. In Kubernetes, seccomp profiles are defined at the pod or container level using the securityContext field. You can reference a profile that is stored on the node filesystem, use the runtime default, or use the special value Unconfined, which disables seccomp entirely.
The Kubernetes default profile, which is applied automatically starting in Kubernetes version 1.22, blocks calls such as mount, umount, pivot_root, iopl, ioperm, and kexec_load. These are calls that could be used to escape a container, modify kernel memory, or gain elevated privileges.
Custom profiles are typically created by running the container with an audit tool like Sysdig Inspect or Falco to record all system calls the application makes, then generating an allowlist profile from that trace. This approach follows the principle of least privilege, granting only the calls the application truly needs. In production, seccomp is considered a critical layer of defense in depth alongside AppArmor, SELinux, and Linux capabilities.
The CNCF Cloud Native Security White Paper identifies seccomp as a mandatory security control for any container workload.
Real-Life Example
Think of a seccomp profile like the rules for entering a high-security research laboratory. To get inside the lab, every visitor must sign in at the front desk and receive a lanyard with a color-coded badge. The badge has a list of rooms the visitor is allowed to enter.
A red badge might allow access only to the lobby and the cafeteria. A blue badge might allow access to the main research floor. A green badge with a chip might allow access to the clean room and the server closet.
There is no universal master badge that opens every door. Now imagine that each door in the lab has a sensor that reads the badge and checks a central database. If the badge does not have permission for that door, the door stays locked and an alarm sounds.
In computing, the Linux kernel is the lab, each system call is a door, and the container or process is the visitor. The seccomp profile is the badge. When the container tries to open a file (a system call called open), the kernel checks the seccomp profile.
If the profile allows that call, the file opens. If not, the kernel blocks the operation. This is far more secure than allowing every process to have unfettered access to all kernel functions.
For a container that only runs a simple web server, it should never need to call something like kexec_load, which loads a new kernel for execution. Blocking that call means even if an attacker somehow gets code execution inside the container, they cannot use that dangerous operation to break out. Just like the lab badge limits physical movement, the seccomp profile limits what the process can do inside the kernel.
Why This Term Matters
Seccomp profiles matter because containers share the host kernel, and that kernel is a huge attack surface. Linux has over 300 system calls, and many of them are designed for systems programming, device drivers, and kernel debugging, not for running web applications. If a container can call any system call, an attacker who exploits a vulnerability in the application can potentially use those dangerous calls to escape the container, escalate privileges, or crash the host.
For example, the system call ptrace allows one process to inspect and control another. If a container can call ptrace, an attacker could attach to another container or even the host system. Mount allows mounting filesystems, which could give access to host directories.
Pivot_root can change the root filesystem, a technique used in container escape exploits. Seccomp profiles close these doors by default. In real IT work, seccomp is a standard part of container security hardening.
Cloud providers like Google Cloud Run enforce seccomp by default. Kubernetes security benchmarks, including the CIS Benchmark for Kubernetes, recommend enabling seccomp and using custom profiles. Without seccomp, your security posture relies entirely on Linux capabilities and AppArmor or SELinux, which are powerful but different tools.
Seccomp specializes in system call filtering, a granularity that capabilities do not provide. Capabilities break down root privileges into units like CAP_SYS_ADMIN, but they still grant broad access. Seccomp can block a single system call while allowing all others.
For DevOps and platform engineers, implementing seccomp is part of building a defense-in-depth strategy. It is especially critical in multi-tenant clusters where containers from different customers run on the same node. A misconfigured or absent seccomp profile could turn a single compromised container into a cluster-wide breach.
The CNCF Cloud Native Security White Paper, the Kubernetes Security Special Interest Group, and the Certified Kubernetes Security Specialist (CKS) exam all emphasize seccomp as a fundamental control.
How It Appears in Exam Questions
In the CKS exam, questions on seccomp profiles appear in several patterns. The most common is a configuration question. The question will give you a Pod YAML with an insecure configuration, such as securityContext set to Unconfined, or no seccomp setting at all.
You must edit the YAML to apply a specific profile, often the RuntimeDefault profile or a custom profile located at a given path on the host. For example, the question might read: 'A security audit has revealed that pod backend-pod is running without seccomp. Apply the RuntimeDefault seccomp profile to the pod.'
You must know the exact YAML syntax for seccomp under securityContext. Another pattern is the troubleshooting question. The exam may describe a scenario where a pod crashes after applying a seccomp profile.
You must analyze the logs, identify that a blocked system call is causing the crash, and either add that call to the allowlist or switch to a broader profile. This tests your understanding of how seccomp errors manifest. A third pattern is the scenario question where you must create a custom profile.
The question gives you a pod that runs a specific binary, and you must first run the pod with an audit profile that logs all system calls, then examine the logs (often provided as a text file), create a JSON allowlist profile, and apply it to the pod. This pattern tests your ability to generate a profile from real traces. A fourth pattern is the comparison question, where you must choose between seccomp, AppArmor, and capabilities for a given attack vector.
For example, 'Which Linux security mechanism prevents the use of the syscall ptrace within a container?' The answer is seccomp. Finally, the exam may include an architecture question about default profiles, such as 'At what Kubernetes version did the default seccomp profile become automatically applied?'
or 'What is the effect of setting seccompProfile to Unconfined in a pod?' Some questions may combine seccomp with other security contexts, asking you to apply seccomp along with an AppArmor profile and a specific user ID.
Study cncf-cks
Test your understanding with exam-style practice questions.
Example Scenario
You are a security engineer at a company that runs a customer-facing web application in Kubernetes. The application is a simple Node.js server that accepts HTTP requests and returns JSON data.
It does not need to interact with hardware, load kernel modules, or monitor other processes. A recent incident report from a security vendor has warned that many container escape exploits rely on the system calls ptrace, mount, and pivot_root. Your task is to harden the pod against these attacks.
You decide to apply the RuntimeDefault seccomp profile, which blocks these dangerous calls. You edit the pod specification to include a securityContext field with seccompProfile set to RuntimeDefault. After applying the change, you test the application and find that it still works correctly because the Node.
js runtime only uses common system calls like read, write, open, and close. The application runs safely. Later, the security team decides to create an even more restrictive custom profile by running the pod with a seccomp audit profile for a week, collecting the logs, and generating an allowlist.
The custom profile further reduces the attack surface by blocking calls like socketpair and fork that the application never needs. This scenario shows how seccomp profiles, from default to custom, provide a layered defense against container escapes.
Common Mistakes
Thinking seccomp and AppArmor do the same thing.
Seccomp filters system calls while AppArmor restricts file paths, network access, and process capabilities. They operate at different layers in the kernel. Seccomp intercepts the call before it reaches the kernel, AppArmor applies MAC rules to the file and network operations.
Use seccomp for system call filtering and AppArmor for filesystem and network restrictions. They are complementary, not interchangeable.
Setting seccomp to Unconfined because the pod crashed with the default profile.
Unconfined disables seccomp entirely, removing all protection. The pod crashes because the application needs a system call that is blocked. The correct fix is to create a custom profile that allows that specific call rather than disabling all filtering.
Run the pod with an audit profile to log all system calls, then create a custom allowlist profile that includes only the necessary calls.
Assuming the default seccomp profile is applied automatically in all Kubernetes versions.
Only Kubernetes 1.22 and later apply the RuntimeDefault profile automatically if the node supports it. In earlier versions, seccomp was opt-in. Many organizations still run older clusters.
Always verify the Kubernetes version and explicitly set seccompProfile to RuntimeDefault in your pod specs if you want the protection.
Writing the seccomp profile JSON with incorrect syscall names.
The kernel expects exact syscall names like clock_gettime, not variations like clock_get_time or clock. A typo in the JSON means the call will not be matched and will fall to the default action, often killing the process.
Use tools like strace or audit to get the exact syscall names from the kernel, and double-check the spelling against the Linux man pages.
Placing the seccomp profile JSON in a ConfigMap instead of on the node filesystem.
Kubernetes seccomp profiles must be present on the node filesystem at a location readable by the kubelet, such as /var/lib/kubelet/seccomp/. ConfigMaps are not automatically mounted there, so the pod will fail to start with an error like 'no such file or directory'.
Store the profile JSON on every node in the cluster, or use a DaemonSet to distribute the file. Alternatively, in newer Kubernetes versions you can use a sidecar container to mount the profile, but the exam expects knowledge of node-level storage.
Exam Trap — Don't Get Fooled
The exam presents a pod YAML with securityContext.seccompProfile set to 'RuntimeDefault' inside a container specification, not at the pod level. Know the version history of seccomp in Kubernetes.
For versions before 1.19, seccomp was annotation-based. For 1.19 to 1.21, the securityContext field existed but RuntimeDefault was not the default. For 1.22+, pod-level seccomp works.
Always check the Kubernetes version stated in the question before applying your configuration. When in doubt, use the annotation method for backward compatibility.
Commonly Confused With
AppArmor is a Linux Security Module that controls file paths, network access, and process capabilities, while seccomp controls system calls. AppArmor profiles are written in a different text format and apply to paths, not syscalls. Seccomp profiles are JSON and apply to kernel functions.
AppArmor can block a container from writing to /etc/shadow, but it cannot block the openat system call. Seccomp can block the openat system call completely, but it cannot restrict which file is opened. You need both for full protection.
Capabilities break the root user into distinct privileges like CAP_NET_ADMIN or CAP_SYS_ADMIN. They control broad categories of privileges. Seccomp controls individual system calls, which is much more granular. Capabilities cannot block a specific system call like ptrace unless you drop the entire capability that contains it, which might also remove other needed privileges.
To block the mount system call, you could drop CAP_SYS_ADMIN, but that would also remove many other privileges like swapon and sethostname. With seccomp, you can block exactly the mount system call while keeping all other calls under CAP_SYS_ADMIN if needed.
SELinux is a mandatory access control system that labels files, processes, and ports with security contexts and enforces policies. It operates at the filesystem and process level. Seccomp operates at the syscall level. SELinux policies are complex and system-wide, while seccomp profiles are per-container and simpler to write.
SELinux can prevent a container from reading files with a certain label, but it cannot prevent the container from making the syscall ptrace to another process. Seccomp can block ptrace regardless of file labels. They are used together in hardened systems.
Step-by-Step Breakdown
Understanding System Calls
Every program running on Linux makes requests to the kernel called system calls. These include opening files, creating network sockets, forking processes, and many more. There are over 300 system calls in a modern kernel. A container without seccomp can make any of these, which is dangerous.
Seccomp Mode Selection
Linux supports three seccomp modes. Mode 1, strict mode, allows only read, write, exit, and sigreturn. Mode 2, seccomp-bpf, allows custom filtering using Berkeley Packet Filter rules. Mode 2 is what Docker and Kubernetes use. The kernel decides which mode to enter based on the profile loaded.
Profile Structure
A seccomp profile is a JSON file with three main sections. The defaultAction sets what happens when a syscall is not explicitly listed, usually SCMP_ACT_ALLOW or SCMP_ACT_ERRNO. The architectures field lists CPU architectures like SCMP_ARCH_X86_64. The syscalls array lists each syscall with its own action and arguments.
Applying the Profile in Kubernetes
In a Pod spec, you add securityContext with seccompProfile. The profile type can be RuntimeDefault (uses container runtime default), Localhost (path to custom profile on node), or Unconfined (no seccomp). For Localhost, you also specify localhostProfile with the filename stored in /var/lib/kubelet/seccomp/.
Generating a Custom Profile
To create a custom profile, first run the container with a profile that audits all syscalls. Use the action SCMP_ACT_LOG to log calls without blocking them. After the container runs its normal workload, inspect the logs using journalctl or a tool like Sysdig. Create an allowlist profile that lists only the syscalls you saw, with defaultAction set to SCMP_ACT_ERRNO.
Testing and Iteration
Apply the custom profile to the pod. If the pod crashes, check the pod logs for 'operation not permitted' or 'seccomp: killed process' messages. Add the missing syscall to the allowlist and reapply. Iterate until the pod runs normally. This is a standard workflow in production.
Practical Mini-Lesson
Seccomp profiles are one of the most effective controls you can implement to secure container workloads, yet they are often overlooked because they require some effort to configure correctly. In practice, professionals need to understand not just how to apply a profile, but how to create, test, and maintain one. The first step is to know your application.
If you are running a Go binary, it might need system calls like sched_yield and futex that a Node.js app does not. If you are running a database like PostgreSQL, it may need shared memory syscalls like shmget and shmat.
Blindly applying a generic profile can break your application. Therefore, the industry best practice is to use a two-phase approach. Phase one is discovery. Run the application in a staging environment with a seccomp profile that uses defaultAction SCMP_ACT_LOG.
This logs every system call without blocking it. Let the application run through its normal operations, including user login, file uploads, database queries, and any periodic jobs. Collect the logs from journalctl or from the container runtime logs.
Phase two is profile generation. Use a script or a tool like inspektor-gadget to parse the logs and extract a unique list of system calls. Build a JSON profile with defaultAction set to SCMP_ACT_ERRNO, which will block any unexpected call, and then list each discovered call with action SCMP_ACT_ALLOW.
Apply this profile to the pod and watch the application closely for a few days. If you see crashes, check the logs again, add the missing calls, and redeploy. Over time, you will have a stable, minimal profile.
Another practical consideration is storage. The profile must exist on every node where the pod can run. You can manage this with a DaemonSet that copies the profile file to a shared host path, or use a Kubernetes feature called seccomp profiles as objects, which is available in newer Kubernetes versions but not in the CKS exam scope.
It is crucial to version your profiles and store them in a Git repository as part of your infrastructure as code. Finally, remember that seccomp is not a silver bullet. It does not protect against vulnerabilities in allowed system calls, such as buffer overflows in the socket or open call handlers.
You must still keep your kernel patched, run with the least privilege, and use other security controls like read-only root filesystems and runAsNonRoot. Seccomp is one layer in a layered defense.
Memory Tip
Think of seccomp as a bouncer at the kernel door. The bouncer has a list of who is allowed in. If your name is not on the list, you stay outside.
Covered in These Exams
Related Glossary Terms
Frequently Asked Questions
What is the default seccomp profile in Kubernetes?
Starting with Kubernetes 1.22, the default seccomp profile is RuntimeDefault, which is applied automatically to all pods if the node supports it. This profile blocks 44 dangerous system calls.
Can I use seccomp without Kubernetes?
Yes, seccomp is a Linux kernel feature. You can apply it to any process using the prctl system call. Docker also applies a default seccomp profile to containers even when not running under Kubernetes.
How do I create a custom seccomp profile?
First, run your container with an audit profile that logs all system calls without blocking them. Collect the logs, extract the unique syscall names, and create a JSON file that allows only those calls.
What happens if a blocked system call is attempted?
The kernel kills the process with a SIGKILL signal if the profile uses SCMP_ACT_KILL, or returns an error with errno if it uses SCMP_ACT_ERRNO. The pod will crash or log an error.
Is seccomp enough to secure a container?
No. Seccomp is one layer of defense. You should also use AppArmor, SELinux, Linux capabilities, read-only root filesystem, runAsNonRoot, and regular audit logging for full protection.
Does seccomp work on all Linux distributions?
Seccomp is built into the Linux kernel, so it works on any distribution that runs a modern kernel (2.6.12 or later). However, some cloud providers or container runtimes may not enable it by default, so you should verify.
How do I test if seccomp is working?
You can run a container with a seccomp profile that blocks a common call like chmod, then attempt to change file permissions inside the container. The operation should fail with a permission error or the container should crash.
Summary
Seccomp profiles are a critical security mechanism for containerized environments, allowing you to restrict the system calls a container can make to the Linux kernel. By limiting available system calls to only those the application actually needs, you dramatically reduce the attack surface and block many common container escape techniques. The feature is built into the Linux kernel and is natively supported by Docker, containerd, and Kubernetes.
In Kubernetes, you can apply the default RuntimeDefault profile or create custom profiles for greater restriction. The CKS exam tests your ability to configure, troubleshoot, and create seccomp profiles, making this a high-priority topic for certification candidates. In real-world IT, implementing seccomp is a standard part of container security hardening and is recommended by the CIS Kubernetes Benchmark and the CNCF security white paper.
Remember that seccomp works best as part of a layered security strategy alongside AppArmor, capabilities, and user namespaces. Start by using the default profile, then move to custom profiles for production workloads. With seccomp, you control exactly what your containers can ask the kernel to do, turning a wild west of system calls into a tightly governed, auditable process.