What are Seccomp Profiles in Container Security?
Learn how seccomp profiles restrict syscalls to harden containers, with a Kubernetes example and common interview pitfalls.
Expected Interview Answer
A seccomp (secure computing mode) profile is a Linux kernel feature that restricts which system calls a process is allowed to make, and in container security it is used to shrink a container’s syscall surface down to only what its application actually needs, blocking everything else at the kernel boundary.
A profile is a JSON policy listing a default action, typically SCMP_ACT_ERRNO to block, plus an explicit allow-list of syscalls the container is permitted to invoke, such as read, write, and openat, while dangerous rarely-needed syscalls like ptrace, mount, or reboot are left off the list and denied. Container runtimes like Docker and containerd apply a default seccomp profile automatically that blocks roughly 44 of the several hundred available Linux syscalls, but Kubernetes lets you attach a custom, tighter profile per Pod via the securityContext.seccompProfile field, referencing a localhost JSON file or the RuntimeDefault. The critical security value is that most container escape and privilege-escalation exploits rely on a specific rarely-used syscall, so denying it at the kernel level blocks the exploit even if the attacker already has code execution inside the container. Building a correct profile that is neither too loose nor breaks the application typically involves generating one from a trace of the application’s actual syscalls during normal operation.
- Shrinks the syscall attack surface a compromised process can exploit
- Blocks many container-escape techniques at the kernel boundary
- Works even after an attacker already has code execution inside the container
- Can be tailored per workload for tighter security than the runtime default
AI Mentor Explanation
A seccomp profile is like a strict list of shots a young batter is allowed to play in a coaching drill — only defensive blocks and straight drives are permitted, while risky shots like the reverse sweep are simply not on the approved list. If the batter attempts a shot outside that list, the coach stops the drill immediately regardless of intent. This narrows what could possibly go wrong during practice, even if the batter’s technique has hidden flaws. The approved shot list is built by watching what shots a batter of that level actually needs in matches.
Step-by-Step Explanation
Step 1
Profile the application
Trace which syscalls the application actually makes during normal operation.
Step 2
Author the allow-list
Write a JSON profile with a default deny action and an explicit list of required syscalls.
Step 3
Attach it to the workload
Reference the profile via securityContext.seccompProfile in the Pod spec (or RuntimeDefault as a baseline).
Step 4
Test and monitor
Run in a permissive/audit mode first to catch missing syscalls before enforcing, then monitor for denials.
What Interviewer Expects
- Understanding that seccomp restricts syscalls, not network or filesystem paths directly
- Knowledge of the default deny plus explicit allow-list model
- Awareness of the Docker/containerd default profile versus a custom Kubernetes profile
- Ability to explain why this blocks exploits even after code execution is achieved
Common Mistakes
- Confusing seccomp with AppArmor/SELinux, which restrict files and capabilities, not syscalls directly
- Writing an overly permissive profile that provides little real restriction
- Not testing a new profile in audit mode before enforcing it in production
- Believing seccomp alone is sufficient without capability dropping or MAC policies
Best Answer (HR Friendly)
“A seccomp profile is a security policy that limits exactly which low-level system operations a container is allowed to perform, blocking everything else by default. Even if an attacker manages to run malicious code inside a container, a tight seccomp profile stops them from using the dangerous system calls they would need to break out or escalate privileges.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: hardened-app
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/hardened-app.json
containers:
- name: app
image: myapp:1.0
# hardened-app.json (excerpt)
# { "defaultAction": "SCMP_ACT_ERRNO",
# "syscalls": [ { "names": ["read","write","openat","close"],
# "action": "SCMP_ACT_ALLOW" } ] }Follow-up Questions
- How is a seccomp profile different from an AppArmor or SELinux policy?
- How would you safely roll out a new, stricter seccomp profile to production?
- Why do most container escape exploits rely on a specific rarely-used syscall?
- What is the Docker/containerd default seccomp profile and what does it block?
MCQ Practice
1. What does a seccomp profile primarily restrict?
Seccomp filters syscalls at the kernel level, independent of network policy or image provenance controls.
2. What is the typical default action model for a hardened seccomp profile?
A strong profile denies by default (e.g. SCMP_ACT_ERRNO) and lists only the syscalls the application actually needs as allowed.
3. Where is a custom seccomp profile referenced in a Kubernetes Pod spec?
Kubernetes attaches a seccomp profile per Pod or container via the securityContext.seccompProfile field.
Flash Cards
What is a seccomp profile? — A Linux kernel policy restricting which syscalls a process may invoke.
What is the strong default action model? — Deny by default, explicitly allow only required syscalls.
Where do you attach a custom profile in Kubernetes? — spec.securityContext.seccompProfile on the Pod or container.
Why does seccomp matter after an exploit? — It blocks the rare syscalls most escape/privilege-escalation exploits depend on, even post-compromise.