Before diagrams and configuration, a few foundational definitions the rest of this guide depends on.

A Docker container is not a virtual machine. It does not run its own copy of the Linux kernel. Instead, every container running on a host shares that host’s single kernel, and is merely given the illusion of isolation through two kernel features: namespaces (which make a container see only its own processes, network interfaces, and filesystem, rather than the host’s full view) and cgroups (which limit how much CPU, memory, and other resources a container can consume). This is precisely what makes containers lightweight compared to virtual machines — but it also means that if a process inside a container somehow breaks out of its intended boundaries, it is breaking out into the very same kernel the host operating system itself depends on, not into some separate, disposable sandbox.

AppArmor and SELinux are both examples of a Mandatory Access Control (MAC) system — a security mechanism that restricts what a process is allowed to do at the kernel level, according to a centrally defined policy, regardless of what permissions the process’s own user account might otherwise have. This is fundamentally different from the ordinary Linux file permissions most people already know (the read/write/execute bits you see when you run ls -l), which are called Discretionary Access Control (DAC) — “discretionary” because the file’s owner decides who can access it. A MAC system sits on top of DAC and can override it: even if a file’s permissions would normally allow access, a MAC policy can still say no.

Why does this matter for Docker specifically? Because container isolation via namespaces and cgroups, while genuinely useful, was never designed as a hard security boundary on its own — it was designed primarily for resource management and process organization. AppArmor and SELinux add the missing piece: an enforced, kernel-level policy that restricts exactly what a containerized process can touch — which files it can read, which system calls it can make, which capabilities it can use — even if a bug, a misconfigured application, or a malicious actor manages to run arbitrary code inside that container.

It’s worth being precise about who these two systems are actually restricting. A common misconception is that AppArmor and SELinux exist to stop an outside attacker from getting into a container in the first place — but that job belongs to other controls entirely, like network firewalls, authentication, and application-level input validation. AppArmor and SELinux operate on a different, later assumption: that despite all those earlier defenses, an attacker (or a bug, or a misbehaving dependency) has already managed to execute some amount of arbitrary code inside the container. Their job starts at that point, asking a much narrower question repeatedly: given that this code is now running, what specifically is it allowed to do to the rest of the system? This is precisely why security professionals describe them as a “second line of defense” or a “post-compromise” control — they assume compromise is possible and limit its consequences, rather than trying to prevent compromise from ever happening.

This framing also explains why these systems are relevant even for organizations that already invest heavily in vulnerability scanning, code review, and secure coding practices. No amount of upstream diligence reduces the probability of a serious vulnerability to exactly zero — a previously unknown flaw in a widely used library, a subtle logic error in custom application code, or a misconfigured dependency can all still lead to a compromised process running inside a container. AppArmor and SELinux exist specifically for the moment those other defenses fail, which is also precisely the moment an organization can least afford to have no remaining protection at all.

Both AppArmor and SELinux plug into the exact same underlying kernel framework, which is why understanding one makes the other far easier to learn.

The Linux kernel exposes a set of internal checkpoints, called hooks, at almost every point where a process attempts a security-relevant action — opening a file, creating a network socket, mounting a filesystem, sending a signal to another process. The Linux Security Modules (LSM) framework is the standardized interface that lets a security system register itself at those hooks and answer a simple question each time: “should this specific action, by this specific process, be allowed right now?”

Critically, both AppArmor and SELinux are what’s called additional, not replacement, security layers. They run their checks after the normal discretionary permission checks have already passed. This means a request must clear ordinary file permissions and the MAC policy to succeed — either one alone can deny an action, but neither alone is sufficient to allow one. A denied AppArmor or SELinux rule always wins over an otherwise-permitted file permission.

Neither system is “better” in an absolute sense — which one a given Docker host uses is usually decided by which Linux distribution it runs, since each distribution ships with one or the other enabled and integrated by default, and running both simultaneously on the exact same host is unusual and generally unsupported.

It’s worth noting that AppArmor and SELinux are not the only LSM-based options that exist — the same framework also hosts smaller, more narrowly focused modules such as Smack (Simplified Mandatory Access Control Kernel, aimed at simplicity for embedded and mobile use cases) and Seccomp‘s own LSM-adjacent hooks for syscall filtering, which is discussed in more depth in the security deep-dive chapter later in this guide. For mainstream Docker deployments on general-purpose server distributions, however, AppArmor and SELinux are overwhelmingly the two systems an operator will actually encounter, which is why this guide focuses on them specifically.

One more subtlety worth internalizing early: both systems are capable of confining far more than just Docker containers. They were originally built to confine ordinary system daemons and services — a web server, a mail server, a print spooler — running directly on the host, long before containers became a mainstream way to package and deploy applications. Docker’s integration with each system is, in a sense, a relatively late addition that reuses infrastructure originally designed for a broader purpose. This lineage matters practically: documentation, tooling, and troubleshooting techniques written generically for AppArmor or SELinux on Linux almost always apply directly to the container use case as well, since the underlying mechanism is exactly the same one being pointed at a containerized process instead of a traditional system service.

To appreciate what these two systems add, it helps to see exactly what Docker provides on its own, before either one is involved.

A freshly started Docker container, with no additional security options specified, already benefits from several layers Docker configures automatically: namespaces isolate its view of processes, network interfaces, mount points, and hostname; cgroups cap its resource consumption; and Docker also drops a subset of Linux capabilities by default — capabilities being fine-grained slices of what was traditionally the single, all-powerful “root” privilege, such as the ability to bind to network ports below 1024, or the ability to change file ownership.

Despite these defaults, a container without a MAC system still retains meaningful reach into the kernel. It can typically still make most system calls, mount certain filesystem types, trace other processes it can see, and — this is the part that concerns security teams most — if a container escape vulnerability is found in the kernel or in Docker itself, namespaces and cgroups alone do very little to limit what an attacker can do once they’ve broken out of the intended boundary, because those two mechanisms were never designed to defend against a deliberate, actively hostile process in the first place.

To make this concrete, consider what “escaping” a container actually tends to look like in practice. It rarely resembles dramatically breaking down a locked door. More often, it looks like a process discovering it can write to a file or directory it was never supposed to reach — for instance, a misconfigured mount that exposes part of the host filesystem inside the container, or a kernel interface under /proc or /sys that, if writable, can be used to influence the host system rather than just the container’s own isolated view of it. Namespaces are supposed to prevent a container from even seeing these host-level resources in the first place, but a bug in how a namespace is set up, or a deliberately crafted request that exploits an edge case in that setup, can occasionally punch a hole through. A MAC policy provides a second, independent check on exactly this kind of access — one that does not rely on the namespace boundary having been implemented correctly, because it evaluates the specific file, path, or label being targeted directly, on every single attempt, rather than trusting that the container’s view of the filesystem was correctly restricted upstream.

flowchart TB
    subgraph Host["Docker Host — One Shared Kernel"]
      direction TB
      NS["Namespaces\n(what the container can SEE)"]
      CG["Cgroups\n(how much it can CONSUME)"]
      MAC["AppArmor / SELinux\n(what it is ALLOWED to DO)"]
      K["Linux Kernel"]
      NS --> K
      CG --> K
      MAC --> K
    end
    C["Container Process"] --> NS
    C --> CG
    C --> MAC
    style MAC fill:#111,stroke:#dc2626,color:#fff
    

A closer look at how AppArmor is structured, and the vocabulary needed to read or write a profile.

AppArmor’s core building block is the profile — a plain-text file, written in a relatively human-readable syntax, that lists exactly what a program is allowed to do: which files it can read, write, or execute, which network operations it can perform, and which Linux capabilities it may use. A profile is attached to a program primarily by its file path, which is the defining trait of AppArmor’s approach — this is why it’s described as path-based, in contrast to SELinux’s label-based approach covered in the next chapter.

• Profile — the policy document itself, defining allowed and denied actions for a given program or container.
• Enforce mode — the profile’s rules are actively applied; any action not explicitly permitted is blocked and logged.
• Complain mode — the profile’s rules are evaluated but not enforced; violations are only logged, which is invaluable for building a new profile without breaking anything while you observe what a program actually needs.
• Capability rules — statements within a profile granting or denying specific Linux capabilities, like capability net_bind_service,.
• File access rules — statements specifying a path and a permission, such as /var/log/app/** rw, to allow read-write access to everything under that log directory, and nothing else.

Docker ships with a built-in profile called docker-default, generated to cover the common needs of a typical containerized application while blocking a well-known set of higher-risk operations — for example, it denies writing to most of /proc (a virtual filesystem that exposes sensitive kernel and process information), denies mounting new filesystems from inside the container, and denies a container from modifying its own AppArmor profile at runtime. On a Docker host with AppArmor enabled, this default profile is applied automatically to every container unless a different profile, or no profile at all, is explicitly requested.

SELinux solves the same underlying problem as AppArmor but with a fundamentally different, more abstract policy model built around labels rather than paths.

Instead of attaching rules to file paths, SELinux attaches a security context — often just called a label — to every single file, process, network port, and other kernel object on the system. A label typically looks like system_u:system_r:container_t:s0, made up of a user, a role, a type, and an optional sensitivity level. Policy rules then say things like “a process labeled container_t may read a file labeled container_file_t,” entirely independent of what the actual file path happens to be. If a file is moved or renamed, its label — and therefore its access rules — travel with it, which is a meaningfully different behavior from AppArmor’s path-based approach.

• Type Enforcement (TE) — the specific SELinux mechanism most relevant to containers, where the “type” component of a label is what policy rules primarily key off of; container processes typically run under the type container_t.
• Enforcing mode — SELinux actively blocks and logs any action a policy doesn’t explicitly allow.
• Permissive mode — SELinux logs what would have been blocked, without actually blocking it, useful for testing new policy the same way AppArmor’s complain mode is.
• Multi-Category Security (MCS) — an additional labeling layer, heavily used by container runtimes, that assigns each container a unique random category so that even two containers running under the identical container_t type are still prevented from accessing each other’s files, adding isolation between containers of the same “type.”

Zooming into the exact moment a container process attempts an action, to see how the kernel decides yes or no.

When a process inside a container attempts a security-relevant operation — say, opening a file — the kernel does not go straight to that file. First, the ordinary discretionary permission check runs (does this user have read access, according to standard Unix file permissions?). If that check fails, the request is denied immediately and the LSM framework is never even consulted. If it passes, the kernel then calls into whichever LSM module is active — AppArmor or SELinux — passing along details of the request: which process is asking, and what exactly it’s trying to do.

This entire sequence happens on essentially every security-relevant system call a containerized process makes, and it happens in the kernel itself — meaning it cannot be bypassed, disabled, or tricked by anything running inside the container, no matter how much control an attacker has gained over the containerized application’s own code. The policy check is enforced by code the container has no access to modify.

A concrete walkthrough of what actually happens, step by step, when a containerized process tries something its policy forbids.

The concrete mechanics of using AppArmor profiles with Docker containers, from the built-in default to writing a fully custom profile.

The recommended workflow for building a genuinely custom profile — one tighter than the generic docker-default — follows the “complain mode” pattern mentioned earlier: run the container with a draft profile in complain mode, exercise the application through its normal, legitimate workflows, then review the resulting log entries to see exactly which file accesses and capabilities the application actually used. Those observed accesses become the allow rules in the final profile, which is then switched to enforce mode. This produces a profile custom-fit to that specific application, far narrower than the generic default, without the tedious guesswork of manually enumerating every file the application might touch.

The equivalent mechanics for SELinux-enabled hosts, where the flags and workflow differ from AppArmor’s even though the underlying goal is identical.

The :z versus :Z distinction on volume mounts deserves its own callout, because it trips up nearly everyone new to SELinux and Docker together: lowercase :z applies a shared label, meaning multiple containers can all be granted access to the same host directory; uppercase :Z applies a private label, meaning only that one specific container is granted access, and any other container attempting to use the same directory will be denied by SELinux even if it’s the exact same host path. Choosing between the two is a genuine design decision, not just a syntax detail: a shared configuration directory that several sidecar-style containers legitimately need to read from calls for :z, while a directory holding one specific container’s private working data — logs it alone writes, a cache only it should read — calls for :Z, so that a compromise of any other container on the host cannot reach data that was never meant to be shared with it in the first place.

An honest look at what running AppArmor or SELinux with Docker actually costs, alongside what it protects.

The practical trade-off in most organizations is not “should we use a MAC system at all” — since one is usually already enabled by default on the chosen Linux distribution — but rather “should we invest engineering time writing custom, tightly-scoped profiles for our own applications, or rely on the generic default profile everyone gets out of the box.” The generic default is meaningfully better than nothing; a custom, tailored profile is meaningfully better than the generic default, at the cost of the authoring and maintenance effort described above.

There is also a quieter, longer-term trade-off worth naming: the cost of institutional knowledge. A generic default profile requires no one on the team to understand AppArmor or SELinux deeply — it simply works, silently, in the background. A custom, tailored policy requires at least someone on the team to genuinely understand the syntax, the tooling, and the debugging workflow well enough to write it, review it, and eventually update it as the application evolves. Teams that skip building this knowledge often find that a well-intentioned custom profile, written once by an engineer who has since moved to a different project, becomes something nobody feels confident touching — at which point the “temporary” workaround of loosening a rule to unblock a deployment quietly becomes permanent, because revisiting it correctly feels riskier than leaving it alone. Investing early in enough shared understanding to maintain custom policy confidently is, in practice, as important as the initial decision to write one.

AppArmor and SELinux are powerful, but neither is meant to be the only line of defense around a container. Here’s how they fit alongside the other Docker security controls.

Docker’s overall container-security posture is typically built from several independent, overlapping controls, and AppArmor/SELinux is just one of them. Linux capabilities restrict which root-equivalent privileges a container’s processes can use at all, regardless of MAC policy — for example, dropping the CAP_SYS_ADMIN capability prevents a huge range of privileged operations outright, before AppArmor or SELinux even get involved. Seccomp (secure computing mode) filters restrict which raw system calls a container is allowed to make at all, operating at an even lower level than capabilities. Running a container as a non-root user inside the container is yet another independent layer, ensuring that even a successful compromise of the application doesn’t automatically inherit root-level privileges within the container’s own namespace.

These layers are deliberately overlapping rather than mutually exclusive, following the classic security principle of defense in depth: a real attacker attempting a container escape typically has to defeat several of these independent controls in sequence, not just one, because each layer restricts the attack surface from a different angle. A missing capability drop might still be caught by a seccomp filter; a permissive seccomp policy might still be caught by an AppArmor rule; a gap in an AppArmor profile might still be caught by the container simply not running as root. No single layer is expected to be perfect on its own — the strength comes from the combination.

Seccomp deserves a slightly closer look given how often it’s discussed in the same breath as AppArmor and SELinux. Where a MAC system reasons about objects — files, paths, labels — seccomp reasons about the raw system calls themselves, the fundamental requests a process makes directly to the kernel (open a file, create a socket, fork a new process, and so on). Docker ships with a default seccomp profile that blocks a curated list of dangerous or rarely-needed syscalls — including several related to kernel module loading, raw system reboots, and certain low-level namespace and clock manipulation calls — while allowing the broad set of syscalls ordinary applications actually rely on. The distinction matters in practice: a MAC policy might permit a process to open a particular file, but seccomp could still block the specific syscall variant used to do so, or vice versa. Because the two systems reason about completely different things — one about objects and paths, the other about the raw operations themselves — they catch genuinely different classes of misuse, which is exactly why security guidance consistently recommends layering both rather than treating either as a substitute for the other.

Running as a non-root user inside the container closes yet another distinct gap. Even a perfectly configured MAC policy and seccomp filter still permit some set of legitimate actions — and if the process attempting those actions happens to be running as root inside the container’s own user namespace, any bug in how that policy was written, or any action that was accidentally left permitted, tends to be far more damaging than the same gap would be for a process running as an unprivileged user. This is why security guidance for Docker consistently recommends specifying a non-root user in a Dockerfile (via the USER instruction) as a baseline practice, independent of whatever MAC or seccomp policy is also in place — it’s a cheap, simple control that shrinks the blast radius of nearly every other kind of security gap, including ones nobody has thought of yet.

Both systems generate a rich, precise audit trail — the single most useful tool for both debugging and security investigation.

Every denial, from either AppArmor or SELinux, is written to the Linux kernel’s audit subsystem, typically surfaced through the standard system log (often visible via journalctl or in /var/log/audit/audit.log on SELinux systems, and in /var/log/kern.log or dmesg output on many AppArmor systems). Each entry records precisely which process attempted which action, under which profile or label, and whether it was allowed, denied, or merely logged in complain/permissive mode.

A number of purpose-built tools exist specifically to make this raw log data usable rather than overwhelming. On SELinux systems, audit2allow reads through recorded denials and automatically generates a draft policy module that would have permitted them — an enormously useful starting point when writing or refining a custom policy, though the generated rules should always be reviewed rather than trusted blindly, since audit2allow simply reports what was denied without judging whether it should have been allowed. On AppArmor systems, similar tooling (commonly bundled as aa-logprof or aa-genprof) walks through complain-mode log entries interactively, letting an operator approve or reject each observed access as it builds up a profile.

Approaches worth deliberately adopting, and pitfalls worth deliberately avoiding, when running AppArmor or SELinux alongside Docker in production.

Practical guidance drawn from how teams successfully run AppArmor and SELinux alongside Docker in real production environments.

These systems are not academic curiosities — they were built specifically to answer real operational and compliance pressure around running untrusted or semi-trusted code safely.

Across these examples, a consistent thread emerges: neither AppArmor nor SELinux was designed as a container-specific technology first — both predate widespread container adoption by years, having been built to confine ordinary system processes and services. Their application to Docker containers is a natural extension of a much older, well-tested idea: don’t trust a process, however legitimate it looks, to only do what it’s supposed to do — enforce that boundary at the kernel level instead, where the process itself has no ability to override the decision.

Compliance-driven industries offer one more instructive example worth calling out on its own. Standards and frameworks that govern how organizations must handle sensitive data — covering areas like healthcare records, payment card data, or government information — increasingly expect documented evidence of “least privilege” enforcement at the infrastructure level, not just at the application or account level. Being able to point to an enforced AppArmor profile or SELinux policy, backed by an audit log showing denied access attempts, gives an organization concrete, kernel-level evidence for exactly this kind of control during a compliance audit — evidence that’s considerably harder to produce convincingly if the only isolation in place is namespaces and cgroups, which were never designed with that audit trail in mind.

In practice, no — a given Linux kernel typically has a single active LSM module for this kind of mandatory access control at any one time, and most distributions ship with one or the other, not both, enabled by default. Running one is standard; combining them is unusual and generally not a supported configuration.

No. They are complementary, independent layers, as covered in the security deep-dive chapter. Running as non-root reduces what a compromised process could theoretically do even without any policy denial; AppArmor/SELinux restricts what it’s actually permitted to do at the kernel level regardless of which user it’s running as. Using both together is stronger than relying on either alone.

For the overwhelming majority of real-world workloads, the performance overhead is negligible — these checks are lightweight kernel-level lookups, not expensive operations. Extremely high-throughput, syscall-heavy workloads may see a very small measurable difference, but this is rarely a practical reason to disable either system.

Not necessarily — it could equally be ordinary Unix file permissions, a missing Linux capability, or a seccomp restriction. The fastest way to confirm is checking the relevant denial log (covered in the observability chapter); if AppArmor or SELinux is the cause, the log entry will say so explicitly, naming the specific profile or label and the specific action that was denied.

It will likely make the immediate error disappear, but it also permanently removes a layer of defense in depth for that container unless deliberately re-enabled later — a trade-off that should be a documented, conscious decision, not a quick workaround adopted under time pressure and then forgotten.

Yes, at the fundamental level — Kubernetes runs containers through the same underlying container runtimes that implement these LSM integrations, and simply exposes AppArmor profile names or SELinux options as fields in its own Pod security configuration, rather than reinventing the underlying enforcement mechanism.

The host’s Linux distribution is the biggest clue — Ubuntu, Debian, and SUSE-family systems default to AppArmor, while Red Hat, Fedora, CentOS, and Rocky Linux-family systems default to SELinux. Beyond that, each system has its own status command (checking whether its kernel module is loaded and which mode it’s running in) that confirms it directly rather than relying on distribution alone, which is worth doing since either system can also be disabled by a previous administrator.

Both systems can express some network-related rules — AppArmor can restrict network address families and socket types a profile is allowed to use, and SELinux can label and restrict access to specific network ports. However, neither is a substitute for dedicated network security controls like firewalls or the service-mesh-level authorization policy discussed elsewhere; they add one more layer of restriction specifically at the kernel’s process-to-resource boundary, not a full network security solution on their own.