As the Docker ecosystem grows up and stabilizes, the security topics of this product are gaining more and more attention. When designing your infrastructure, you cannot avoid the issue of Docker security.

Docker already has some great security features built in:

• Docker containers are minimal: one or more working processes, only the necessary software. This reduces the possibility of being affected by software vulnerabilities.
• Docker containers perform a specific task. It is known in advance what should be done in the container, paths to directories, open ports, daemon configurations, mount points, etc. are defined. Under such conditions, it is easier to detect any security-related anomalies. This principle of system organization goes close with microservice architecture, allowing you to significantly reduce the attack surface.
• Docker containers are isolated from both: host and other containers. This is achieved in case of ability of the Linux core to isolate resources using cgroups and namespaces. But there is a serious problem – the core has to be divided between the host and containers.
• Docker containers are reproducible. Because of their declarative build system, any administrator can easily figure out what the container was made of and how. Very seldom you will end up with an unknown legacy system that nobody wants to reconfigure. It’s familiar, isn’t it? 😉

However, there are weaknesses in Docker-based systems too. In this article, we’ll talk about Docker host and core security.

Core and host of Docker: main security points

Description

In a compromised system, isolation and other container safety mechanisms will not help a lot. In addition, the system is designed in such way, that containers use the host core. For many reasons, this increases work efficiency, but from a security point of view, this feature is a threat that must be fixed.

Best practices

The topic of Linux host security is very extensive and a lot of literature has been written about it. Regarding Docker:

• Make sure the host and Docker engine configurations are secure (access is limited and granted only to authenticated users, the communication channel is encrypted, etc.) To check the configuration for compliance with best practices, we recommend to use Docker bench audit tool.
• Timely update the system, subscribe to the newsletter about the security of the operating system and other installed software, especially if it is installed from third-party repositories (for example, container orchestration systems, one of which you probably already installed).
• Use minimal host systems specifically designed for use with containers, such as CoreOS, Red Hat Atomic, RancherOS, etc. This will reduce the attack surface, as well as take advantage of convenient features such as executing system services in containers.
• To prevent unwanted operations on both the host and containers, you can use the Mandatory Access Control system. Tools like Seccomp, AppArmor, or SELinux can help you with this.

Examples:

Seccomp allows you to limit the actions available for the container, especially – system calls. This is something like firewall, but for a core call interface.

Some privileges are blocked by default. Try the following commands:

# docker run -it alpine sh
/ # whoami
root
/ # mount /dev/sda1 /tmp
mount: permission denied (are you root?)

or:

/ # swapoff -a
swapoff: /dev/sda2: Operation not permitted

It is possible to create a custom Seccomp profile, for example by prohibiting calls to chmod.

Let’s download the default Seccomp profile for Docker:

https://raw.githubusercontent.com/moby/moby/master/profiles/seccomp/default.json

While editing the file, you will see a whitelist of system calls (in the area of line 52), remove chmod, fchmod and fchmodat from it.

Now launch the container with this profile and check the operation of the established restrictions:

# docker container run --rm -it --security-opt seccomp=./default.json alpine sh
/ # chmod +r /usr
chmod: /usr: Operation not permitted

Well done!