Wiki · Concept · Last reviewed June 25, 2026

Kubernetes AppArmor

Kubernetes AppArmor support lets pods and containers use Linux mandatory access-control profiles through their security context.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, AppArmor, securityContext, sandboxing, AI governance

Definition

AppArmor is a Linux security module that uses profiles to restrict what a program can access. Kubernetes documentation describes it as a way to confine Pods by applying AppArmor profiles to containers. The Kubernetes AppArmor tutorial marks field-based AppArmor support as stable in Kubernetes v1.31 and enabled by default.

In Kubernetes, AppArmor is configured through the securityContext.appArmorProfile field at pod or container scope. It belongs to the same hardening family as seccomp and SELinux, but it focuses on program access to resources such as files, Linux capabilities, and network operations rather than syscall filtering alone.

How It Works

Kubernetes documentation says an AppArmor profile can be specified at the pod level or at the container level. If both are set, the container profile takes precedence. Prior to Kubernetes v1.30, AppArmor was specified through annotations; current documentation directs users to the security-context field.

The documented profile types are RuntimeDefault, Localhost, and Unconfined. RuntimeDefault uses the container runtime's default AppArmor profile. Localhost uses a profile already loaded on the host and names it through localhostProfile. Unconfined runs without AppArmor enforcement.

Node and runtime support matter. The Kubernetes tutorial says AppArmor must be installed and enabled on the Linux kernel, the container runtime must support AppArmor, and the requested profile must be loaded onto each node that may run the workload. Kubernetes does not provide a built-in mechanism for loading custom AppArmor profiles onto nodes.

The security-context documentation adds an operational distinction. If a container explicitly sets appArmorProfile.type: RuntimeDefault, the Pod will not be admitted if AppArmor is not enabled on the node. If the field is omitted, the default is also RuntimeDefault, but it is only applied when the node has AppArmor enabled.

Agent Context

Agent and model infrastructure often places untrusted code near useful authority: browser automation, code execution tools, retrieval pipelines, data converters, plugin sandboxes, model-serving adapters, and temporary workers. AppArmor does not inspect prompts or model outputs. Its value is lower in the stack: it can restrict what the containerized process is allowed to read, write, execute, or access after it starts.

That makes AppArmor useful evidence in AI workload governance. A sandbox claim should not stop at "runs in Kubernetes." It should say which kernel controls are active, whether the workload is privileged, which profile is expected, how profile drift is detected, and what happens when a profile blocks a file write or other disallowed action.

Governance Use

A governance record should preserve the profile type, pod or container scope, localhostProfile name when used, profile source repository, profile hash, rollout method, node-label or RuntimeClass constraints, runtime version, owner, testing evidence, and rollback path. For Localhost profiles, the record should also identify how each eligible node receives the profile before scheduling.

Review should connect AppArmor to Pod Security Standards. The Baseline policy says the default RuntimeDefault profile should not be overridden or disabled except for allowed profile values, and it permits RuntimeDefault and Localhost. Privileged namespaces, break-glass exceptions, or profiles set to Unconfined should have explicit owners and expiration.

Limits

AppArmor is not a full sandbox. Kubernetes documentation says privileged containers ignore any applied AppArmor profiles, and privileged mode can override or undo other hardening settings. AppArmor also depends on Linux node support, runtime support, correct profile loading, and profile quality.

Custom profiles can be difficult to maintain. The Kubernetes tutorial says profile authoring can be tricky and points operators toward system logs such as dmesg when debugging denials. A profile that is too loose gives weak protection; a profile that is too tight can break legitimate workload updates. AppArmor should sit beside seccomp, user namespaces, NetworkPolicy, image admission, RuntimeClass isolation, and audit logging.

Source Discipline

Claims about feature state, profile types, pod and container fields, node requirements, default behavior, privileged-container limits, logging, and Pod Security Standards should cite Kubernetes documentation. Claims about AI systems should be framed as operational inferences from deploying agent and model infrastructure as pods.

Spiralist Reading

Spiralism reads AppArmor as a named boundary around a program's reach.

The workload may still be flawed, rushed, or manipulated. But the profile records a refusal: this process does not receive the whole filesystem, the whole host, or the whole machine merely because it can ask.

Sources

Return to Wiki