A container is a regular Linux process wearing a blindfold — and the blindfold is thinner than most people think.

A container is not a tiny virtual machine

A virtual machine carries its own kernel, so an attacker who breaks into it still faces a second wall before reaching the host. A container does not have that luxury. It is simply a process that the kernel has been told to show a limited view of the world: its own list of processes, its own network, its own file tree. Underneath, the same kernel serves every container on the node.

That shared kernel is the heart of the matter. Every time a program wants to do something real — open a file, send a network packet, start another program, allocate memory — it must ask the kernel through a special request called a system call. The Linux kernel offers well over three hundred of these on a typical 64-bit Intel or AMD machine, and each one is a door into the most powerful code on the server.

Most programs use a tiny slice of what the kernel offers

A typical web service needs a few dozen system calls to read configuration, listen on a port, talk to a database, write logs and exit politely. Even a big application rarely uses more than around a hundred. The rest — calls that load kernel modules, reboot the machine, swap the root file system, or trace other processes — sit unused, waiting for someone with bad intentions to find a bug in them.

Security people call this idea reducing the attack surface. If your container cannot even ask for a dangerous operation, then a flaw hiding behind that operation can never be reached from inside your container. You do not have to know about the flaw in advance. You simply closed the door.

The story of a compromised web app

Seccomp and AppArmor are two layers in a stack. You need to know the other layers to understand why you still need these two.

When a container runtime such as containerd starts your container, it does not call one magic “make safe” function. Instead it stacks several independent Linux features on top of each other. Each one answers a different question, and each one can fail or be misconfigured without the others noticing. Knowing the full stack helps you decide where a profile fits and what it cannot do.

flowchart TD
    A["Your application process"] --> B["Namespaces: limited view"]
    B --> C["Cgroups: limited resources"]
    C --> D["Capabilities: limited powers"]
    D --> E["Seccomp: limited system calls"]
    E --> F["AppArmor or SELinux: limited resources by name"]
    F --> G["Shared Linux kernel"]
        

Read the diagram from top to bottom. A request from your application passes every layer on its way down. Any layer can say no. That is why security folks speak of defence in depth: you assume one layer will eventually have a hole and make sure the next layer catches what slipped through.

What each layer controls

Seccomp stands for “secure computing mode,” and it is the kernel’s built-in bouncer for system calls.

First, what is a system call?

Programs run in a restricted area called user space. They cannot directly touch the disk, the network card or the memory manager. To do anything real, they raise their hand and ask the kernel by number: “please do request number 257 with these details.” That request is a system call, and the kernel answers it in a privileged area called kernel space. Everyday things like reading a file, creating a socket or starting a thread are all system calls underneath.

Because every meaningful action passes through this single narrow gateway, it is the perfect place to put a checkpoint. That is exactly what seccomp does: it inspects each request at the gateway and decides what to do with it before the kernel acts.

How seccomp grew up

How a filter works inside the kernel

A seccomp filter is attached to a thread. Every child process or thread created afterwards inherits it, and once attached it can never be removed — only made stricter by stacking another filter on top. When several filters exist, the kernel runs them all and obeys the most restrictive verdict. This one-way design is crucial: even if an attacker takes over the process, they cannot loosen the rules.

For each system call the filter sees the call number, the processor architecture and the raw values of up to six arguments. It compares these against its rules and returns a verdict. Because the filter looks at plain numbers, it is very fast, and it cannot be fooled by clever naming.

flowchart LR
    A["Process makes a system call"] --> B{"Seccomp filter checks number, architecture and arguments"}
    B -->|"Allowed"| C["Kernel runs the call"]
    B -->|"Return an error"| D["Process gets a permission error and keeps running"]
    B -->|"Kill"| E["Process is terminated with a bad-system-call signal"]
    B -->|"Log"| F["Call runs and an audit record is written"]
        

The common verdicts, in plain words

A profile is just a structured list that tells the runtime how to build the kernel filter for you.

Nobody writes BPF by hand for containers. Instead, container runtimes follow a standard JSON profile format originally popularised by Docker and now shared across the container ecosystem. The runtime reads the file, translates it into a BPF program and installs it just before your application starts. You only need to understand the pieces of the file.

Allow-list or deny-list?

There are two ways to think about a profile. In an allow-list profile, the default action is to block, and you name only the calls you permit. This is the strongest posture because anything you forgot to think about is blocked automatically. In a deny-list profile, the default is to allow and you name specific dangerous calls to refuse. It is easier to write, but it fails open: a call added to a future kernel is allowed until someone notices.

Choosing the right error for blocked calls

For blocked calls, the usual choice is to return an error rather than kill the process. Well-written programs expect that some operations may be refused and have a plan B. Killing the process, by contrast, gives the user a cryptic crash with a bad-system-call signal. Reserve the kill verdict for calls that should never appear at all in your application, where silent continuation would be worse than a crash.

There is one special case worth knowing. When new versions of the standard C library start using a newer system call, they first try it and, if the kernel replies “function not implemented,” they quietly fall back to the older call. If a profile instead returns “operation not permitted” for that unknown newer call, the library does not fall back — it reports a failure. Good profiles return the “not implemented” answer for calls that did not exist when the profile was written. This exact trap broke many containers when a newer thread-creation call appeared, and it is a lesson in why default errors deserve thought.

AppArmor is a Linux Security Module that gives each program a written rule book about the files and resources it may use.

What is a Linux Security Module?

Normal Linux permissions work on users and groups: if a file is readable by user “web,” then any program running as “web” can read it. This is called discretionary access control because the file’s owner decides. The trouble is that a hacked program inherits every permission of its user, even though it only ever needed a few files.

Linux Security Modules add mandatory access control. The administrator writes rules that apply to a specific program, and even the owner of a file cannot override them. The kernel checks these rules in addition to normal permissions. AppArmor, SELinux and a few others are different implementations of this idea.

How AppArmor thinks

AppArmor is path-based. A profile describes access in terms of file paths and patterns, such as “may read anything under the application folder” or “may never write to the system configuration area.” Profiles are attached to programs, and when that program runs, the kernel enforces its profile on it and on anything it starts if the rules say so.

A profile can cover many kinds of access: reading, writing, appending, memory-mapping files, executing other programs, using specific network families and protocols, holding particular capabilities, sending signals, tracing other processes and mounting file systems. Rules can allow or explicitly deny. A deny rule always wins over an allow rule, which makes it easy to carve out forbidden spots inside otherwise permitted areas.

Everyday tools you will meet

Where AppArmor lives

AppArmor is built into the kernels of Ubuntu, Debian and SUSE-family distributions and is typically enabled out of the box there. Red Hat-family systems prefer SELinux instead. This matters a lot in Kubernetes because the feature only works on nodes whose operating system has AppArmor switched on. Always check the node image your cloud provider or platform team uses before planning around it.

AppArmor versus SELinux in one glance

People often ask which one to choose. The honest answer is that they guard different doors.

Seccomp judges the type of request. AppArmor judges the target of the request. A bank offers a nice parallel: one rule says “customers may deposit and withdraw but never open the vault,” and another says “customers may enter the lobby and the teller area but not the staff corridor.” You want both rules because each catches things the other cannot.

Two attacks, two different catches

Kubernetes itself never talks to seccomp or AppArmor. It passes a request down a chain of helpers until the kernel finally applies it.

It helps to remember that Kubernetes is a manager, not a worker. When you declare that a pod should use a security profile, the control plane simply stores your wish. The real work happens on the node, where several programs hand the wish along like a relay race. Understanding each runner tells you where to look when something goes wrong.

sequenceDiagram
    participant U as Engineer
    participant A as API server
    participant S as Scheduler
    participant K as Kubelet on node
    participant C as Container runtime
    participant R as Low-level runtime
    participant L as Linux kernel
    U->>A: Submit pod with security settings
    A->>S: New unscheduled pod
    S->>A: Chosen node
    A->>K: Pod assigned to this node
    K->>K: Check profile is available and supported
    K->>C: Create container with profile settings
    C->>R: Prepare container specification
    R->>L: Install seccomp filter and AppArmor profile
    R->>L: Start the application process
        

What each runner does

Kubernetes gives you three seccomp choices and two places to set them. Simple on paper, subtle in practice.

The three profile types

Pod level and container level

You can set the profile in the pod’s security settings, where it applies to every container in the pod including init containers, or in a single container’s security settings. A setting on the container wins over the setting on the pod. This lets you give a whole pod the safe default while loosening or tightening one container that has special needs, such as a log shipper or a network helper.

Making RuntimeDefault the cluster-wide default

Historically, if a pod did not mention seccomp, Kubernetes left the container unconfined, which meant no filtering. That surprised many teams, because Docker had applied a default profile for years. Modern Kubernetes lets a node administrator switch the kubelet so that any pod without an explicit setting receives the runtime default automatically. This feature went through alpha and beta stages and became generally available in Kubernetes 1.27.

Turning it on is one of the highest-value, lowest-effort security moves available. It raises the floor for every workload, including ones nobody remembers to configure. The cost is that a small number of older or unusual applications may break, so test it in a staging cluster first and keep a short list of workloads that need an explicit exception.

A short history, so old blog posts make sense

How the profile type interacts with other settings

Two other settings change how seccomp behaves. A container marked as privileged effectively runs without the seccomp filter, so asking for a profile on a privileged container gives a false sense of security. And the setting that forbids privilege escalation turns on a kernel flag that stops the process from gaining extra powers through special executable files, which also supports safe filter installation. A well-hardened pod combines a runtime-default or custom seccomp profile, no privilege escalation, dropped capabilities and a read-only root file system.

AppArmor in Kubernetes follows the same idea as seccomp, with one big extra requirement: the node must already know the profile.

The three profile types

From annotations to a real field

For many years AppArmor in Kubernetes was configured through pod annotations whose names included the container’s name. It worked but was awkward, easy to typo and hard to validate. Starting with Kubernetes 1.30, AppArmor support became generally available through a proper field in the security settings, at both pod and container level, with the same three types you saw for seccomp. The older annotations are deprecated, and you should migrate manifests to the field-based form.

What the default profile typically restricts

The runtime’s default AppArmor profile is intentionally broad but useful. It stops containers from mounting file systems, from writing to many sensitive entries in the kernel’s process and system information areas, and from tracing processes that belong to other profiles. Most ordinary applications never notice these limits. They matter only when an attacker, or a clumsy tool, tries to reach beyond the container’s own space.

Controlling where pods land

If you cannot put the profile on every node, label the nodes that carry it and add node selectors or affinity rules to the pods that need it. The scheduler will then place those pods only where the profile exists. This is a practical bridge, but the long-term goal should be uniform nodes with profiles delivered automatically, so scheduling stays simple.

The default profiles are the quiet heroes of container security. Knowing what they do tells you what you get for free.

When people say “RuntimeDefault,” they mean the profile shipped by the container runtime. The seccomp version grew out of the one that Docker introduced around 2016 after studying which calls normal containers needed. It is an allow-list with a long set of permitted calls and a carefully chosen group of blocked ones. It aims for maximum compatibility with minimum risk, which is why it is safe to switch on almost everywhere.

Kinds of calls the default blocks

Why compatibility is the design goal

A default that breaks applications would be switched off by frustrated teams, giving no protection at all. So the designers chose to block calls that nearly no application uses and to allow conditionally the ones that need strong capabilities. A web server, a database or a batch job almost never trips over the defaults. Applications that do are usually system-level tools, such as debuggers, network analyzers, container-in-container builders and some security agents.

When the default is not enough

Writing a good profile is half the job. Delivering it to every node, every time, is the other half.

Where the files must live

For seccomp, a Localhost profile is a file on the node’s disk inside a dedicated folder under the kubelet’s working directory. The pod refers to it by a path relative to that folder. If the file is missing, the container cannot be created, and the pod shows an error in its events. For AppArmor, the profile must be loaded into the node’s kernel under a known name, not merely stored as a file.

Because Kubernetes does not copy these files for you, you need a delivery method. Teams usually pick from the following approaches, often combining two of them.

Protecting the delivery path

The folder holding profiles is a sensitive spot. Anyone who can write a loose profile there, or load a permissive AppArmor profile under a trusted name, can quietly weaken your protection. Treat profile files like code: store them in version control, review changes, sign or checksum them where possible, and restrict who and what can write to the node locations.

Versioning profiles with applications

A profile and the application it protects are a matched pair. When the application adds a feature that needs a new system call, the profile must change in the same release. Name profiles with a version or release tag, roll them out before the application update, and keep the previous version around so you can roll back quickly. This avoids the nasty situation where a new application version meets an old profile on some nodes.

The goal is a profile tight enough to matter and loose enough to never page you at three in the morning.

The biggest fear around custom profiles is breaking production. That fear is justified if you write a profile once, in a hurry, and flip it to enforcing mode. It disappears when you follow a staged workflow that learns first, tests second and enforces last.

flowchart LR
    A["Record behaviour in a test environment"] --> B["Merge and review the call list"]
    B --> C["Deploy in log-only mode"]
    C --> D["Watch real traffic and fix gaps"]
    D --> E["Switch to enforcing mode"]
    E --> F["Monitor and update with each release"]
    F --> A
        

Common reasons recordings miss things

A Kubernetes add-on that treats security profiles as first-class cluster objects instead of loose files.

The Security Profiles Operator, often shortened to SPO, is a project in the Kubernetes special interest group ecosystem. An operator is a program that runs inside the cluster and keeps reality matching a declared description. SPO takes the painful parts of profile management — recording, storing, distributing and binding — and turns them into ordinary Kubernetes resources that you can create, review and delete with the same tools you use for everything else.

flowchart TD
    A["Engineer applies a profile object"] --> B["Operator controller in the cluster"]
    B --> C["Node agent on every node"]
    C --> D["Profile file or loaded profile on the node"]
    E["Pod refers to the profile"] --> F["Kubelet and runtime"]
    D --> F
    G["Recording request for a workload"] --> B
    B --> H["Generated profile object from observed behaviour"]
        

What the operator gives you

Recording with the operator

A recording request selects workloads by label and asks the operator to watch them. When the workloads finish or are deleted, the operator produces a profile object containing the calls it saw. You then review that object like any other change and attach it to the workload. This shortens the learn step of the workflow from days of scripting to a few declarative objects.

A profile that engineers may forget to request protects nobody. Policy makes the safe choice the default and the unsafe choice visible.

Pod Security Standards

Kubernetes defines three built-in levels of pod hardening, called the Pod Security Standards. They are privileged, baseline and restricted. Seccomp is part of this scheme. The baseline level forbids explicitly setting seccomp to unconfined. The restricted level goes further and requires the seccomp type to be either the runtime default or a custom Localhost profile. These standards give you a shared vocabulary and a ready-made checklist.

Pod Security Admission modes

The built-in admission controller applies a chosen level to a namespace using labels. It has three modes that you can combine. Enforce rejects pods that break the rule. Audit lets them run but writes an annotation in the audit log. Warn lets them run but prints a warning to the person who submitted the pod. A smart rollout uses warn and audit first, collects the list of offenders, fixes them, and only then turns on enforce.

Going beyond the built-in levels

The built-in standards do not know about your custom profile names, nor can they insist that a particular AppArmor profile be used. For that, teams use policy engines such as Kyverno or OPA Gatekeeper, or the built-in validating admission policy feature. These can check that every pod in a namespace has a seccomp type set, that Localhost profiles come only from an approved list, that privileged containers are not used, and can even add the setting automatically through mutation when a pod forgot it.

A safe rollout plan

A blocked call that nobody sees is either a hidden outage or a hidden attack. You need to see both.

Where seccomp violations show up

When a filter blocks a call with an error, the application usually just sees a failure and carries on, so the kernel’s own log is the best witness. Kernels write seccomp audit records when a process is killed by the filter or when the log verdict is used. These appear in the node’s audit system or kernel messages as records of a specific type, containing the process number, the system call number and the architecture. Translating a call number back to a name needs a lookup table, which is why the operator’s log enricher is so handy.

Where AppArmor denials show up

AppArmor writes readable lines that include the word “DENIED,” the operation attempted, the profile name, and the file path or resource that was refused. In complain mode the same lines appear with the word “ALLOWED” so you can see what would have been blocked. Because the path is included, these lines are far easier to understand than raw seccomp records.

Signals worth watching

Turning logs into alerts

Collect the node audit logs into your central logging system. Create dashboards counting denials by namespace, workload and profile. Alert on sudden jumps, which often follow a deployment that changed behaviour, and on any denial involving especially dangerous calls, which may indicate an intrusion attempt. Pair this with a runtime detection tool such as Falco, which watches system calls and process behaviour and can flag things like a shell starting inside a container that never runs shells.

When a profile breaks something, a calm, ordered approach finds the cause faster than guessing.

Symptom to cause lookup

Teams worry that security filters will slow everything down. In practice the cost is small, and the compatibility questions matter more.

Is there a speed penalty?

Seccomp filters run for every system call, so a very large or poorly structured filter adds a little time to each one. Kernel developers have worked to keep this tiny: modern kernels can cache the decision for simple allowed calls so that repeat calls skip most of the work. For typical web services and databases, the difference is hard to measure. Only programs that make millions of tiny system calls per second might notice, and even then the effect is usually a small percentage.

AppArmor adds checks whenever a program touches files or other controlled resources. Rules are compiled into an efficient form when loaded, and the overhead is generally low. Extremely heavy file workloads with huge numbers of path lookups can see more impact than average, which is a good reason to benchmark in your own environment before and after.

Compatibility questions that deserve attention

Honest security means knowing where your protection ends. Profiles are strong, but they are not a force field.

Attacks they commonly blunt

What they cannot do

When you need a stronger wall

If you run code written by strangers, such as a platform that executes customer programs, a shared kernel with filters is not enough. Stronger isolation approaches put a barrier between the workload and the host kernel. Some intercept system calls in a user-space kernel written in a memory-safe language. Others run each pod inside a lightweight virtual machine with its own kernel. Both cost some performance and compatibility but raise the bar substantially.

Teams that succeed with profiles tend to repeat the same good habits. Teams that struggle tend to repeat the same four mistakes.

Patterns that work

Anti-patterns to avoid

Profiles work best when they sit inside a wider hardening plan. This chapter helps you decide how far to go for each workload.

A simple decision path

Not every pod deserves a handcrafted profile. Spending a week tuning an allow-list for a small internal tool wastes effort that could protect your payment service. A short decision path keeps the work proportional to the risk. Ask how exposed the workload is, how sensitive its data is, and how much you trust the code it runs.

flowchart TD
    A["New workload"] --> B{"Runs code you do not trust?"}
    B -->|"Yes"| C["Use a sandboxed runtime plus profiles"]
    B -->|"No"| D{"Internet facing or handles sensitive data?"}
    D -->|"Yes"| E["Build a custom seccomp profile and an AppArmor profile"]
    D -->|"No"| F["Use RuntimeDefault for both layers"]
    E --> G["Add policy checks and monitoring"]
    F --> G
    C --> G
        

The diagram is deliberately simple. Everything flows into the same final step, which is policy and monitoring, because even the lowest-risk workload should be covered by a baseline rule and visible in your logs. The difference between paths is only how much custom work sits in the middle.

Controls that should travel with every profile

Seccomp and AppArmor are strongest when the process holding them has little power to begin with. Several simple settings in the pod’s security section shrink that power and cost almost nothing to apply.

Controls around the pod

Profiles protect a running container, but attackers have other ways in. Reduce the chance of an initial break-in by scanning images for known flaws, keeping base images small, and patching often. Restrict the network paths a compromised pod could use with network policies, so a hacked service cannot freely reach databases or the metadata service of the cloud provider. Limit what the pod’s service account token can do with careful role-based access rules, since stolen tokens are a favourite target. Finally, patch the node operating system and the container runtime, because a filter cannot protect against a bug in a call you must allow.

Who owns what

Profiles fail most often because nobody is sure whose job they are. A clear split of responsibilities avoids this. The platform team owns the cluster-level pieces: node images, the kubelet defaults, the profile delivery mechanism, admission policy and the central log pipeline. Application teams own the behaviour of their own workloads: they provide the test suites that exercise every feature, review recorded call lists, and fix their code or libraries when a call looks suspicious. The security team sets the minimum standards, approves exceptions, and reviews the dashboards for anything unusual.

When these three groups meet regularly, even for thirty minutes a month, profile work stops being a surprise that lands on one tired engineer. Exceptions get reviewed before they become permanent. Upgrades are planned with profile testing in mind. And when a real incident happens, everybody already knows where the logs are and who can change what.

Measuring progress

Choose a few simple measures and track them monthly. The percentage of pods with an explicit non-unconfined seccomp setting shows coverage. The number of unconfined or privileged exceptions shows how much risk you are knowingly carrying. The number of custom profiles with a current recording shows freshness. The count of denials investigated within an agreed time shows whether monitoring is real. Report these to security leadership in plain language, with trend arrows, so that progress is visible and funding for the work is easier to justify.

If you remember only one chapter for your next architecture review, make it this one.

A review checklist you can reuse

Seccomp and AppArmor are not niche research toys. They quietly protect software you probably used today.

They answer different questions, so using both gives better protection than either alone. If your nodes do not support AppArmor, seccomp plus dropped capabilities plus a non-root user is still a strong baseline, and on SELinux-based systems SELinux plays AppArmor’s role.

Make the runtime default seccomp profile apply to every workload, either through the kubelet default setting or through admission policy. It costs little, protects everything, and breaks very few applications.

Most ordinary applications run fine. Problems appear mostly with system-level tools such as profilers, network analyzers and programs that build containers inside containers. Test in staging, watch the logs and keep a small exception list.

The container cannot be created, and the pod’s events explain that the profile could not be loaded. This is intentional: failing loudly is safer than running unprotected.

No. Seccomp sees system call numbers and raw argument values but cannot read the file name stored behind a pointer. Use AppArmor, SELinux or file permissions for path-based control.

In practice a privileged container runs without the usual seccomp and AppArmor restrictions, so naming a profile on it provides a false sense of safety. Remove the privileged setting before relying on profiles.

The seccomp annotations were removed from Kubernetes in version 1.27, and the AppArmor annotations are deprecated since the field-based form became generally available in 1.30. Always move to the field-based settings and verify the result on a running pod.

Record it. Use the recorder in the Security Profiles Operator, tracing tools, or node-level gadgets while running a thorough test suite. Then review the list manually before using it as an allow-list.

An error is the safer default for most calls, because well-written software handles refusals gracefully. Use the kill verdict only for calls that must never occur, where continuing would be dangerous. For calls that do not yet exist in your profile’s era, return a not-implemented error so libraries can fall back.

Yes for seccomp, which is a kernel feature available on virtually all node images. For AppArmor, check whether your provider’s node image has it enabled. For custom profiles you need a delivery method that works without logging into nodes, such as the Security Profiles Operator.

Usually the overhead is too small to notice. Heavy workloads that make enormous numbers of tiny system calls or file operations may see a small cost, so measure in your own environment.

Not for most workloads. Custom profiles are worth the effort for internet-facing services, applications that process untrusted input, and systems that handle especially sensitive data.

The built-in standards check that seccomp is not unconfined at the baseline level and that it is set to the runtime default or a Localhost profile at the restricted level. They do not check the contents of your custom profile or AppArmor names, which is where policy engines come in.

No. A shared kernel with filters reduces risk but does not give a hard boundary. For hostile tenants, combine profiles with a sandboxed runtime that provides a separate kernel layer or user-space kernel.

Whenever the application, its dependencies, its base image, the container runtime or the node kernel changes in a meaningful way. Automating re-recording and testing in your pipeline makes this routine instead of heroic.

Containers share one kernel, and that shared kernel is both their strength and their biggest risk. Seccomp narrows which requests a container may make to that kernel, and AppArmor narrows which files and resources it may touch. Kubernetes lets you apply both through simple settings, but the real craft lies in delivering profiles to every node, building them from observed behaviour, rolling them out gradually, and watching the results. Start with the runtime defaults everywhere, enforce them with policy, and add custom profiles only where the risk justifies the effort. Done this way, profiles stop being a scary source of outages and become a quiet, reliable layer of defence that keeps small mistakes from turning into big incidents.