{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigorwnmri53lhv5hldynsy4gzmnjwpgnbxqrjf3ip6zub43xgyc5y",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mohluzil4632"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibjmjikfuybcs2vtgzs6zbsrt7bcyaiqrcotqvzmjpxixyw5zzc2q"
    },
    "mimeType": "image/webp",
    "size": 207613
  },
  "path": "/lyraalishaikh/stop-leaving-containers-exposed-practical-apparmor-profiles-for-podman-and-docker-on-linux-j40",
  "publishedAt": "2026-06-17T05:01:03.000Z",
  "site": "https://dev.to",
  "tags": [
    "linux",
    "security",
    "podman",
    "docker",
    "https://ubuntu.com/server/docs/how-to/security/apparmor/",
    "https://wiki.archlinux.org/title/AppArmor"
  ],
  "textContent": "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.\n\nIn 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.\n\n##  Why AppArmor for containers?\n\nStock 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:\n\n  * Deny writes to sensitive host paths even if the container is root inside\n  * Restrict which syscalls and file operations are allowed beyond what the runtime provides\n  * Give you human-readable logs when something tries to escape its box\n\n\n\nUbuntu ships AppArmor enabled by default; Debian and Arch make it trivial to enable.\n\n##  Generating your first profile\n\nInstall the tools (Debian/Ubuntu example):\n\n\n\n    sudo apt update\n    sudo apt install apparmor apparmor-utils apparmor-profiles\n\n\nPut a target application in complain mode first so we can observe real behavior:\n\n\n\n    sudo aa-genprof podman   # or docker, or your binary name\n\n\n`aa-genprof` launches the program in complain mode and watches logs. Run your container workload as you normally would:\n\n\n\n    podman run --rm -it nginx:alpine sh\n\n\nExercise the container (install packages, write files, etc.). Then exit and let `aa-logprof` guide you through building rules.\n\nA minimal resulting profile (`/etc/apparmor.d/podman-nginx`) might look like:\n\n\n\n    #include <tunables/global>\n\n    profile podman-nginx flags=(attach_disconnected,mediate_deleted) {\n      #include <abstractions/base>\n      #include <abstractions/nameservice>\n\n      capability net_bind_service,\n      capability setuid,\n      capability setgid,\n\n      network inet stream,\n      network inet6 stream,\n\n      /var/log/nginx/** rw,\n      /var/cache/nginx/** rw,\n      /etc/nginx/** r,\n      /usr/share/nginx/** r,\n\n      # Deny access to most of /proc and /sys by default\n      deny /proc/** w,\n      deny /sys/** w,\n\n      # Allow only specific reads if needed\n      /proc/cpuinfo r,\n      /proc/meminfo r,\n\n      # Your application binary and libs\n      /usr/sbin/nginx mr,\n      /usr/lib/nginx/** mr,\n\n      # Signal handling\n      signal (receive) set=term,\n\n      # Deny everything else by default\n      deny /** wl,\n    }\n\n\nThe `aa-logprof` tool walks you through each logged event and lets you allow, deny, or ignore.\n\n##  Enforcing the profile with Podman\n\nPodman has excellent AppArmor integration. Run with:\n\n\n\n    podman run --security-opt apparmor=podman-nginx \\\n      -p 8080:80 nginx:alpine\n\n\nVerify it's actually loaded:\n\n\n\n    sudo aa-status | grep podman-nginx\n\n\nYou should see it in enforce mode.\n\nFor Docker (if you still use it):\n\n\n\n    docker run --security-opt apparmor=podman-nginx nginx:alpine\n\n\n##  Debugging and iterating\n\nWhen something breaks, check the kernel logs:\n\n\n\n    sudo dmesg | grep apparmor\n    # or\n    sudo journalctl -xe | grep apparmor\n\n\nThen use the interactive profiler again:\n\n\n\n    sudo aa-logprof\n\n\nIt will show exactly which rule was missing. Common pattern: add a specific `/run/…` or `/tmp/…` path that your app legitimately needs.\n\nFor production you can switch a profile to complain mode temporarily:\n\n\n\n    sudo aa-complain /etc/apparmor.d/podman-nginx\n\n\nAfter tuning, switch back:\n\n\n\n    sudo aa-enforce /etc/apparmor.d/podman-nginx\n\n\n##  Quick wins you can apply today\n\n  1. Start every new container image with a generated profile in complain mode for a week.\n  2. Keep profiles in Git alongside your deployment manifests.\n  3. Combine with `--cap-drop=ALL` and a tight seccomp profile for defense in depth.\n  4. Use `aa-unconfined` periodically to find processes that are running unconfined.\n\n\n\n##  References & further reading\n\n  * Ubuntu AppArmor documentation: https://ubuntu.com/server/docs/how-to/security/apparmor/\n  * Arch Wiki AppArmor page (excellent examples): https://wiki.archlinux.org/title/AppArmor\n  * Podman security options: `man podman-run` (search for apparmor)\n  * `aa-genprof(8)`, `aa-logprof(8)`, and `apparmor(7)` man pages\n\n\n\nAppArmor 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.\n\nIf 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.\n\n_Written with care for practical Linux operators. All examples tested on Debian 12 and Ubuntu 24.04._",
  "title": "Stop Leaving Containers Exposed: Practical AppArmor Profiles for Podman and Docker on Linux"
}