Introduction to Docker Security

Docker is all the rage at the moment, but a few people have asked me to give an overview of security considerations when using Docker. So here’s some notes!

What is Docker? The main docker site actually has a great write up on what the product actually is, called “What is docker?“, but to pull out some key points, Docker allows you to run applications within containers to allow for greater stability, separation and security. If you consider an alternative of running applications within virtual machines to achieve these three goals then Docker is more efficient as it uses a layered file system allowing for better disk usage as common files can be shared. They also share the same operating system kernel, allowing for more efficient use of RAM.

With virtual machines each application can be deployed into a guest separate operating system which runs on a hypervisor on top of a host operating system. Whereas with containerisation each application runs within a separated area of the same operating system, using a single operating system kernel.

Pros and Cons Now there are certainly pros and cons for each option, put simply: if you want full isolation and guaranteed resources then virtualisation is likely the solution. If you want to isolate processes and run a ton of them on a reasonable size host, then containerization is likely the solution.

Docker Security When it comes to Docker security, their own blog contains resources both in regards to how they provide security and information is posted on published vulnerabilities. To summarise both, there are three areas to consider when looking at the security of docker: the security of containers, implemented through namespaces and cgroups; the security Docker daemon itself; the security of the kernel. I think this raises an important point, as the kernel is shared between containers (again, as opposed to with virtualization where each guest runs its own kernel) and any insecurity in the kernel can affect all containers. For example, a vulnerability leading to a kernel panic in one container will take them all down. In regards to the docker command, it’s previously been shown that members of the docker group have a significant amount of privileges on the host, effectively any member of the docker group is root on the host.

The second post I referenced covers two main things, the first is it explicitly gives recommendations for the security of docker: Run Docker Engine with AppArmor or SELinux to provide containment; Map groups of mutually-trusted containers to separate machines; and do not run untrusted applications with root privileges (docker run -u). The second thing is that docker points out that they believe in responsible disclosure of vulnerability information and they even go as far as to have a Docker CVE list on their site. Although it’s important to note that this list, of course, only covers specific vulnerabilites within Docker and won’t give you any pointers on how to avoid security misconfiguration and generic hardening.

Things to consider to harden Docker installations are:

  • Keeping the system kernel updated;
  • Running SELinux or AppArmor;
  • Disabling suid;
  • Using seccomp to disable syscalls;
  • Keeping Docker itself updated;
  • Remapping uids so that the container uid 0 does not match the hosts uid 0;
  • Using iptables to restrict traffic between containers.
  • Do not run applications with root privileges.