Docker security (Part 1)

November 25, 2022


This quote is quoted from the official document of Docker. In this report, we find out is the statement current follow 3 questions:

1/ Which core components participate in which security aspects of Docker, and how?

2/ What are the security vulnerabilities of Docker that could be exploited to attack the application running on a Docker container, the container itself or the container host?

3/ What practices should be done to reduce security risks when using Docker container?

1. Container isolation versus Virtual machine isolation

In Docker containers, each application or container is isolated from others, may make you think that is more security. In fact, they still use the same root. This provides the advantage of simplified management, although it also leads to a few disadvantages. For instance, if the root is compromised, the host containers could be at risk.

Compare to Virtual machine, Docker does have a lower level of isolation than a virtual machine due to the way it shares the kernel with the host. So if the code you are running contains a kernel or physical hardware exploit, that could access the host.

Docker architecture and Virtual machine architecture.
Docker architecture and Virtual machine architecture.

2. Docker security

Docker security refers to the build, runtime, and orchestration aspects of Docker containers. It includes the Dockerfile security aspects of Docker base images, as well as the Docker container security runtime aspects—such as user privileges, Docker daemon, proper CPU controls for a container, and further concerns around the orchestration of Docker containers at scale.

Because Docker has a lot of moving parts. This makes it more complex to secure than other deployment technologies. You need to take a comprehensive approach, because a Docker vulnerability can come from anywhere.

Secure aspects of Docker core components

Compared to virtual machines or bare-metal servers, securing a Docker container is more difficult because Docker environment has much more moving layer. Due to their moving parts, securing containers is complicated, and it requires a high level of vigilance.

4 layers of Docker container security.
4 layers of Docker container security.

In order to understand about Docker security, first we will start to delve into the security aspects for each of the Docker components.

1. Host operating system (layer 1)

As the Docker containers share the OS kernel, host OS security is also a part of Docker security. All the processes will be vulnerable in case the host get compromised, because processes running inside the Docker container are just namespaced processes inside a shared host.

Docker containers share the host OS kernel.
Docker containers share the host OS kernel.

2. Docker daemon (layer 2)

Docker daemon listens for Docker API requests and manages Docker. After listening to the incoming request, Docker daemon interacts with the underlying host kernel do the job. It can also communicate with other daemons to manage Docker services.

Because the Docker daemon can interact with the host kernel, this can be dangerous, especially when running as root. The Docker daemon acts as the brain of the Docker behind the whole operation, so any impact on the Docker daemon will increase both container and host threats.

Docker daemon is the brain of Docker.

2.1. Docker daemon socket

Docker daemon socket is a unique socket which acts as the backbone for managing containers. If others has access to our Docker socket, they could call Docker daemon, manage our containers, images, etc. This is especially dangerous, so protect our Daemon socket is very important.

By default, Docker daemon creates a non-networked Unix domain socket at /var/run/docker.sock and only processes with root permission. This is fine for the basic use case of the default behavior of only accessing the Docker API on the local machine via the socket as the root user. However, if we want to use the Docker demon remotely, it is a difference story.

Docker daemon socket is the intermediate step between Client and Daemon.
2.1.1. Use TLS (HTTPS) to protect the Docker daemon socket

If a client needs to access a Docker daemon remotely, Docker daemon can open a TCP socket and listens on port 2375 for REST API requests. However, default TCP socket provides unencrypted and unauthenticated access to the Docker daemon. This could lead to many security problems, when the root access will give to everyone e who poke us into the TCP port. In this case, Docker support TLS certificates for identity verification.

Authorization service with Docker daemon.
2.1.1. Use SSH to protect the Docker daemon socket

The another solution to protect Docker daemon socket remotely is using SSH. As SSH is widely used, and is often one of the protocols allowed by default, it could be convenient to access the Docker daemon directly via SSH. SSH also uses encryption to secure the connection between a client and a server.

2.2. Mounting volumes

Docker allows mounting to sensitive host directories, and even modify the contents of the host file system directly from the container. For application containers with access to the Internet, it is important to be especially careful when mounting important host directories (/etc, /usr). Any breach can result in data leak or data loss.

Docker volumes can mount host file system.

More articles

Start Your Project

Tell us about your project and get a free consultation

We offer up to 6 months of warranty and dedicated support for all projects. Plus, it's on us if your project exceeds the estimated budget.

Request a project