Docker & AppArmor: 30.000 foot view

Luc Juggery
Aug 24, 2016 · 3 min read

When it comes to the sensitive topic of container security, several options are considered. Among them: kernel capabilities, SELinux, AppArmor, seccomp.

In this short article I’ll explain at a very high level what AppArmor is and how it is used by Docker to enhance container security.

In a nutshell, with AppArmor a system administrator can associate a security profile to each application in order to restrict access to the underlying system. The application is said to be confined within the profile.

What does that mean for Docker container ? Let’s see this on an example.

We first create a Docker host running Ubuntu 16.04 on a DigitalOcean droplet.

$ docker-machine create \
— driver digitalocean \
— digitalocean-access-token=$TOKEN \
— digitalocean-image=ubuntu-16–04-x64 \

Note: ve’ve choosen Ubuntu as AppArmor is installed by default on Ubuntu distribution.

Let’s ssh into the newly created Docker host

$ docker-machine ssh node1

Once there, we can find AppArmor configuration and profiles into /etc/apparmor.d. During Docker engine installation, a docker-default profile is created in the docker file within that directory.

$ cat /etc/apparmor.d/docker

To keep it simple, AppArmor is path based and defines rules that set access rights to specified resources. In the above file, several rules are defined (network, linux POSIX capabilities, files). More details on the AppArmor profile language can be found on the official wiki.

On our Docker host, let’s give a look at the profiles and the associated processes running AppArmor status (aa-status)

From this output, we can see that no processes are running with the profiles defined. Let’s change that and run a Ubuntu container.

root@node1:~# docker run -ti ubuntu bash

How has the AppArmor status changed ?

We can see that 1 process is now running with docker-default profile (the one defined in /etc/apparmor.d/docker). By default, all container are ran using docker-default profile unless told to use another one.

Let’s then try to run another container not confined in a particular AppArmor profile (we’ll use the --security-opt parameter to do so).

root@node1:~# docker run -ti --security-opt apparmor:unconfined ubuntu bash

If we run aa-status again, we could get the same output as above, meaning no additional process is running with docker-default profile.

We now have one container running with an AppArmor profile and another one that is unconfined. Let’s see how the default profile prevent from doing some actions. We’ll check against the following rule as it is quite easy to show the different of behavior between the 2 containers.

deny @{PROC}/sysrq-trigger rwklx,

On this simple example we can see that the permission denied error only happens in the container confined in the docker-default profile. The unconfined container output an error but passed the permission test.

This very short article only gives a very high level view of what AppArmor is and how it is used when running Docker container. AppArmor is one element used for container security, in some future articles of the “30.000 foot view” series will give an overview of some other elements.


Luc Juggery

Written by

#DockerCaptain #Startups #Software #中文学生 Learning&Sharing


#DockerCaptain. Startup enthusiast. Software guy. Mandarin’s learner. Chocolate eater. Each day should be the opportunity to learn something

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade