Stop Leaving Containers Exposed: Practical AppArmor Profiles for Podman and Docker on Linux

Containers give us isolation, but by default they still share the host's attack surface more than many realize. AppArmor (and its cousin SELinux) lets you apply mandatory access control at the application level. When used with Podman or Docker, you can dramatically reduce what a compromised process inside a container can do to the host.

In this post we'll walk through generating a real profile, enforcing it, debugging violations, and integrating cleanly with your container runtime — all on a typical Debian/Ubuntu or Arch system.

Why AppArmor for containers?

Stock container runtimes already drop capabilities and use seccomp, but AppArmor adds path-based and capability-aware rules that are easy to audit. A profile can:

• Deny writes to sensitive host paths even if the container is root inside
• Restrict which syscalls and file operations are allowed beyond what the runtime provides
• Give you human-readable logs when something tries to escape its box

Ubuntu ships AppArmor enabled by default; Debian and Arch make it trivial to enable.

Generating your first profile

Install the tools (Debian/Ubuntu example):

sudo apt update
sudo apt install apparmor apparmor-utils apparmor-profiles

Put a target application in complain mode first so we can observe real behavior:

sudo aa-genprof podman   # or docker, or your binary name

aa-genprof launches the program in complain mode and watches logs. Run your container workload as you normally would:

podman run --rm -it nginx:alpine sh

Exercise the container (install packages, write files, etc.). Then exit and let aa-logprof guide you through building rules.

A minimal resulting profile (/etc/apparmor.d/podman-nginx) might look like:

#include <tunables/global>

profile podman-nginx flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_bind_service,
  capability setuid,
  capability setgid,

  network inet stream,
  network inet6 stream,

  /var/log/nginx/** rw,
  /var/cache/nginx/** rw,
  /etc/nginx/** r,
  /usr/share/nginx/** r,

  # Deny access to most of /proc and /sys by default
  deny /proc/** w,
  deny /sys/** w,

  # Allow only specific reads if needed
  /proc/cpuinfo r,
  /proc/meminfo r,

  # Your application binary and libs
  /usr/sbin/nginx mr,
  /usr/lib/nginx/** mr,

  # Signal handling
  signal (receive) set=term,

  # Deny everything else by default
  deny /** wl,
}

The aa-logprof tool walks you through each logged event and lets you allow, deny, or ignore.

Enforcing the profile with Podman

Podman has excellent AppArmor integration. Run with:

podman run --security-opt apparmor=podman-nginx \
  -p 8080:80 nginx:alpine

Verify it's actually loaded:

sudo aa-status | grep podman-nginx

You should see it in enforce mode.

For Docker (if you still use it):

docker run --security-opt apparmor=podman-nginx nginx:alpine

Debugging and iterating

When something breaks, check the kernel logs:

sudo dmesg | grep apparmor
# or
sudo journalctl -xe | grep apparmor

Then use the interactive profiler again:

sudo aa-logprof

It will show exactly which rule was missing. Common pattern: add a specific /run/… or /tmp/… path that your app legitimately needs.

For production you can switch a profile to complain mode temporarily:

sudo aa-complain /etc/apparmor.d/podman-nginx

After tuning, switch back:

sudo aa-enforce /etc/apparmor.d/podman-nginx

Quick wins you can apply today

1. Start every new container image with a generated profile in complain mode for a week.
2. Keep profiles in Git alongside your deployment manifests.
3. Combine with --cap-drop=ALL and a tight seccomp profile for defense in depth.
4. Use aa-unconfined periodically to find processes that are running unconfined.

References & further reading

• Ubuntu AppArmor documentation: https://ubuntu.com/server/docs/how-to/security/apparmor/
• Arch Wiki AppArmor page (excellent examples): https://wiki.archlinux.org/title/AppArmor
• Podman security options: man podman-run (search for apparmor)
• aa-genprof(8), aa-logprof(8), and apparmor(7) man pages

AppArmor profiles are one of those "set once, sleep better" tools. The initial investment in learning aa-logprof pays for itself the first time you catch a container trying to do something it shouldn't.

If you're already running Podman or Docker in production without custom AppArmor profiles, this is one of the highest-ROI security improvements you can make this week. Start with one critical service and expand from there.

Written with care for practical Linux operators. All examples tested on Debian 12 and Ubuntu 24.04.