Pin a Per-Container AppArmor Profile via Docker Runtime Flag

Docker and containerd accept the --security-opt apparmor=[profile-name] flag at container creation time, which causes the runtime to write the profile name into the OCI spec's process.apparmorProfile field. The container runtime then asks the kernel to transition the container's init process into that profile via the change_profile interface before exec. The kernel stores the profile pointer on the task struct, and every subsequent syscall by the container's processes is checked against the profile's rules. Profiles must already be loaded into the kernel via apparmor_parser or the docker-default profile shipped by the daemon.

In production this is essential for multi-tenant platforms, CI runners, and any host running untrusted workloads. A custom profile can restrict /proc/sys writes, block ptrace, deny raw socket creation, and confine filesystem access to the container's overlay mount, which is dramatically tighter than the default docker-default profile. It is also used to grant narrow additional capabilities, for example allowing a monitoring sidecar to read host /proc while still blocking execve of arbitrary binaries.

Security-wise, this is one of the highest-leverage controls available on a Docker host because it survives inside the container's namespace and applies to every descendant process. Performance impact is a small constant cost per syscall, measured in single-digit nanoseconds for cache hits. Common pitfalls include referencing a profile that is not loaded, which causes the container to fail to start with a cryptic OCI runtime error; forgetting that --privileged disables AppArmor entirely; and assuming child containers spawned via docker exec inherit the profile, which they do only if the parent profile permits change_profile transitions.

> System.Execute()

sudo apparmor_parser -r /etc/apparmor.d/docker-restricted
docker run --rm -d --name api \
  --security-opt apparmor=docker-restricted \
  --security-opt no-new-privileges \
  -v /srv/api:/srv/api:ro \
  myorg/api:1.4.2

> Architecture & Security Context

Verified for Valters IT Hub. When deploying this configuration in a production homelab or enterprise environment, ensure that you monitor system resources and implement strict access controls. Administrator privileges are required.

ID: VALTERSIT-A29FFA6E2A36