Seccomp vs AppArmor: Which Actually Stops Container Breakouts?

Ask a junior developer how to secure a container, and they’ll probably say, “Just scan the image for CVEs.” Talk to an architect, and they’ll point you straight to the kernel.

By 2026, nobody’s pretending containers are lightweight virtual machines anymore. That myth is dead. A container isn’t a sandbox. It’s just a Linux process, wrapped in namespaces and cgroups, sharing the host’s kernel. The hypervisor sits underneath. If someone manages to pull off Remote Code Execution (RCE) inside your container, the only thing stopping them from taking over the host is the kernel’s defenses.

In our main guide on Hypervisor Kernel Hardening, we established the hypervisor trust boundary. We then measured exactly how memory defenses resist corruption in our deep dive on KASLR and SMEP/SMAP. But here’s the thing: before an attacker even starts poking around in memory, they need to actually talk to the operating system.

That’s where Seccomp and AppArmor come in—these are the real heavy hitters in container security. Engineers mix them up all the time or just turn them off because “they break the app.” But that’s missing the point. Here’s how they really work, and why the choices you make about platforms, runtimes, and trust boundaries suddenly matter a whole lot because of them.

The Boundary Misunderstanding

Let’s clear up a big misunderstanding: most platform teams think the main boundary is between containers. It isn’t.

The real boundary is between what your workload can do and what the infrastructure controls. A container breakout isn’t just about moving sideways—it’s a full-on infrastructure control-plane problem. Once someone compromises the kernel, they don’t just hop into another container. They step right into the node, grab the kubelet identity, and then, well, it’s open season on your cluster.

Seccomp and AppArmor aren’t about protecting workloads. They’re hypervisor protections, just wearing the costume of runtime features.

What Actually Happens During a Real Breakout

So what actually happens when a breakout goes down? Here’s the usual playbook:

1. The attacker gets RCE inside the container.
2. They read the service account token.
3. They talk to the kube-api.
4. They create a privileged pod.
5. They mount the host filesystem.
6. Now, they own the node.
7. Soon after, they own the cluster.

Seccomp interrupts step 5. AppArmor interrupts step 2.

The Mental Model: Verbs vs. Nouns

One limits capability, the other limits reach. To understand the difference, you must understand how a Linux process interacts with the kernel.

When your application wants to do anything—read a file, open a network port, spawn a new process—it must ask the kernel for permission using a System Call (syscall). There are over 300 syscalls in the Linux kernel.

• Seccomp controls the Verbs (What actions the process can take).
• AppArmor controls the Nouns (What files/resources the process can touch).

Seccomp (Secure Computing Mode): Exploit-Class Elimination

Seccomp operates at the absolute lowest level of process interaction. It uses seccomp-bpf (Berkeley Packet Filters) to intercept syscalls before the kernel even processes them.

What Seccomp Actually Removes

Without Seccomp, you defend against individual vulnerabilities. With Seccomp, entire vulnerability categories cannot execute.

Seccomp does not make exploits harder. It makes many exploits impossible. By enforcing a profile, you eliminate critical classes of attacks:

• Kernel introspection exploits: Dropping ptrace.
• Namespace escape primitives: Dropping unshare and setns.
• Kernel module injection: Dropping init_module.
• Keyring credential attacks: Dropping add_key.

Note: The default Docker Seccomp profile blocks roughly 44 of the 300+ available syscalls (though this varies depending on your specific container runtime like containerd or CRI-O). It drops the obvious dangers, but it doesn’t care where the permitted syscalls point.

AppArmor: Preventing Identity Pivoting

If Seccomp is the vocabulary filter, AppArmor is the security guard checking IDs at the door. AppArmor is a Mandatory Access Control (MAC) system.

It binds access control attributes to programs rather than users. You write a profile that says: “The Nginx process is allowed to read /var/www/html/. It is denied access to everything else.”

What AppArmor Actually Protects

Most real cluster compromises do not require deep kernel exploitation. They require credential discovery.

AppArmor’s true architectural value is that it prevents identity pivoting. If an attacker gets RCE inside a container, AppArmor stops them from reaching the identities that control the platform:

• ServiceAccount tokens (/var/run/secrets/kubernetes.io/)
• Kubelet certificates
• Container runtime sockets (/var/run/docker.sock or containerd.sock)
• Cloud metadata endpoints

Seccomp stops becoming root. AppArmor stops becoming powerful.

Precision Note: Because AppArmor is path-based, it can be mathematically weaker against hardlink-based bypasses unless the profile is explicitly configured to mitigate them.

The Real Model: Prevent, Then Contain

Security layers operate in sequence, not in parallel.

If you ask which tool actually stops a breakout, the answer is neither. A resilient architecture relies on cascading failure domains.

Breakouts succeed when all three align. Containers do not fail because one control is missing. They fail because the attacker finds the first missing layer.

The Platform Design Consequence

Because containers share a kernel, cluster design determines security more than configuration. Single-tenant clusters rely on trust. Multi-tenant clusters rely on kernel policy.

This changes how platforms must be built:

• Node pools become trust zones.
• Privileged workloads require dedicated nodes.
• CI runners cannot share nodes with control plane agents.
• Backup agents become infrastructure workloads, not application workloads.

Without this separation, Seccomp and AppArmor only delay compromise—they do not contain it. Container security is therefore a scheduling problem as much as a kernel problem.

The Day-2 Implementation Checklist

These are not best practices. These are conditions required for containers to be safe to run untrusted workloads.

The Architectural Takeaway

As we map out in our Virtualization Architecture Pillar, the hypervisor isolates machines. The kernel isolates workloads. Containers replace the hypervisor boundary with policy.

Virtual machines fail when the hypervisor fails. Containers fail when the kernel is reachable.

Seccomp reduces reachability. AppArmor reduces consequence. Kernel hardening reduces exploitability.

Only together do containers become a platform boundary instead of a convenience abstraction. A container is not a sandbox. It becomes one only when the kernel stops being part of the application’s threat model.

From Policy to Platform Security If you are ready to stop treating infrastructure security as an afterthought and start engineering resilient boundaries, dive into the hands-on Virtualization Security Learning Path.

Architectural References & Further Reading

• Kubernetes Official Documentation: Restrict a Container’s Syscalls with seccom
• Kubernetes Official Documentation: Restrict a Container’s Access to Resources with AppArmor
• Docker Engine Security: The Default Seccomp Profile
• The Linux Kernel Archive: AppArmor Mandatory Access Control
• NCC Group: Understanding and Hardening Linux Containers

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →