Docker & AppArmor: 30.000 foot view
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 \
node1
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.
