How secure is Docker?
Over the past few years, the use of virtualization technologies has increased exponentially. Accordingly, the demand for efficient and secure virtualization solutions is increasing. The two most used virtualization technologies are Container-based virtualization and hypervisor-based virtualization. Of these two types, container-based virtualization is more lightweight as compared to hypervisor-based virtualization and it provides an efficient virtual environment, but containerization can lead to few security concerns.
So in this article, we will look into different types of security concerns and we’ll analyze the security level of Docker. Docker is a well-known representative of container-based approaches and the scope of this article is limited to security threats in docker containers. In this article, let’s talk about docker security and its vulnerabilities but first, understand what is the docker? and for that, I want to introduce docker to all of you.
Docker introduction :
Docker is an OS virtualization software platform that is used to create, deploy and run applications in a Docker container. It is very lightweight when compared to a virtual machine and it allows us to wrap up our application in a container along with all the required libraries and other dependencies and deploy it, so it reduces dependency-related conflicts. Docker helps in the simplification and acceleration of workflow.
Basically, Docker is nothing but an environment where we can run our code or program and it will run in isolation. Generally, when we do some project in docker it isolates which is not the case in a personal machine. For example, if I am doing the project in system-A and need to show the project in system-B then there are chances that our program might get crashed because of various reasons like different compilers, different versions of the software/packages, or different operating system. So docker helps us to keep the project and all the required libraries in a single package and if we need to export our project to a different system then docker will export the entire environment of our project.
Two components of docker:
- Docker Image.
- Docker Container.
Docker defines the Images as follows:
- A Docker image is a read-only template that contains a set of instructions for creating a container that can run on the Docker platform. It provides a convenient way to package up applications and preconfigured server environments, which you can use for your own private use or share publicly with other Docker users.
- Image is an executable package that includes everything needed to run an application -the code, runtime, libraries, environment variables, and configuration files.
Docker defines the containers as follows :
A container is a standard unit of software that packages up code and all its dependencies. So, the application runs quickly and reliably from one computing environment to another. The container is an environment which has all package and all the system required for running the program.
Most people get confused in a docker container and virtual machine. These both are very different. In the virtual machine, we need to install operating system + kernel + drivers but docker uses the host’s system, kernel and driver so it's very lightweight and takes very little space. Now-a-days, docker containers are so much in demand because they are flexible, lightweight, interchangeable, portable, scalable, stackable.
How docker isolates itself?
Linux Cgroups is one of the kernel features provided by Linux, which helps docker to isolate itself. Cgroups allow us to group a set of related processes which can run as a single unit. We can control this group of processes in terms of usage CPU utilization, memory, I/O. Cgroups can have control over the allocation, managing and monitoring of system resources. Hardware resources can also be divided among the tasks and the users which increases efficiency.
Namespaces are the other kernel feature that allows a restricted view of the system. When you login into a Linux machine, you see its file systems, processes, network interfaces. Once you create a container, you enter into a namespace that provides a restricted view and this newly created container has its own file systems, processes and network interface different from the host machine, it’s running on. Each container gets a separate set of kernel resources so that no process can use the resources allocated to other processes.
Is Docker secure?
Most of the newbie developers think that docker is secure and they don’t even do a basic scan of the image which they pulled from the docker hub(docker hub is the world’s largest library and community for container images Browses over 100,000 container images from software vendors, open-source projects, and the community.)Most of the people run randomly Docker images on their system without caring who pushed it or about their authenticity. Docker is not as secure as a virtual machine because a virtual machine does not talk to the host kernel directly. They do not have any access to kernel file systems like /sys and /sys/fs,/proc/*.
It’s simpler to misconfigure docker than it is to misconfigure a virtual machine and the versatility of docker resource sharing opens up further possibilities for both implementation and configuration bugs. However, if you can properly configure the sharing permissions and there are no implementation bugs in Docker or the kernel, Docker offers far more fine-grained sharing than hardware virtualization and can provide you with better overall protection.
In a virtual machine, first the hypervisor would be attacked not the kernel.
Open attack surfaces for Docker containers:
- If the attacker is the one who can start containers (i.e., has access to the Docker API), then he immediately, without further action, has full root access to the host. This is well known for years, has been proven, and is not under debate by anyone (Google or SE immediately give you simple command lines which do not need a particular container to work)
- If the attacker manages to get root inside the container, then you’re in trouble. In effect, he/she can then do pretty arbitrary kernel calls and try to affect the host kernel. Unfortunately, many docker images seem to run their stuff as root and skip the USER in the Dockerfile — this is not a Docker problem but a user problem.
- Vulnerabilities in the kernel Containers on a server share the same kernel as the host, so if the kernel has an exploitable flaw, it could be used to break out of the container and into the host.
- If you have a Bad configuration then you have access to a container that is running with — privileged, you are most likely be able to gain access to the underlying host.
- If you have a container that mounts a host filesystem, you can probably modify things in that filesystem to escalate privileges to the host.
- Mounting the Docker socket inside a container to allow the container to understand the state of the Docker daemon is a relatively common (and dangerous) practice in Docker containers. This gives the host a quick breakout.
Container escape using docker.sock:
- Docker.sock is a unique socket which acts as the backbone for managing your containers, when you type any docker commands using your docker client, your docker client interacts with this docker.sock and manages your container
- By default, when the docker command is executed on a host, an API call to the docker daemon is made via a non-networked UNIX socket located at/var/run/docker.sock.
- This socket file is the main API to control any of the docker containers running on that host.
- However, many containers and guides require you to expose this socket file as a volume within a container or in some cases, expose it on a TCP port.
- Docker containers that expose /var/run/docker.sock, locally or remotely, could lead to a full environment take over.
- Access to /var/run/docker.sock is equivalent to root.
- Now let’s assume that the attacker somehow landed on the container and got a shell on the container where docker.sock is mounted and in this module we’ll see how an attacker can exploit this vulnerability and take over this container.
- First, we need to simulate the environment by creating a container with docker.sock mounted on it, for that I use an alpine image. Let’s start an alpine container and name it as sock using the following command:
$ docker run -itd --name sock -v/var/run/docker.sock:/var/run/docker.sock alpine:latest- Use the following command to get the shell on the sock container.
$ docker exec -it sock sh- Now, we have a container with a docker socket mounted on it , lets see how to exploit it. In the first step, install the docker client inside this container and create another container using this container.
$ apk update
$ apk add -u docker- The following command creates a new container which communicates to the underlying container through Unix socket and -v /:/test:ro mount the root directory of the host to the new container and by using sh it returns the shell of the new container.
$ docker -H unix:///var/run/docker.sock run -it -v /:/test:ro-t alpine sh
- Once we have the shell of the new container, we can go to the /test directory which is the mount point of the root directory of the host.
$ cd /test$ ls
- The output of ls command will list out all the files and directories present in the root directory of host, which implies that we got a foothold of the host machines filesystem.
Exploiting Privileged Container :
- When a container runs with — privileged flag, it gives many capabilities to the container. An attacker who is inside the container can take advantage of these capabilities to escape the container and gain a foothold on the host.
- One of the capabilities provided by — privileged flag is CAP_SYS_MODULE
- Capability, an attacker who has access to the container, with this capability can escape from the container by installing a kernel module directly to the host’s kernel.
- We can use it to get a reverse shell on the host where the privileged container is running.
$ docker run -itd --name priv --privileged alpine
$ docker exec -it priv sh
$ apk add -U libcap
$capsh --print
- Now that we have cap_sys_module capability enabled in our container, we can escape from the container by installing a kernel module directly to the host’s kernel.
Vulnerabilities
- Most of the developers don’t even know about these vulnerabilities.
Now-a-days, docker is widely in use and most of the developers who work with docker think that it is very secure but the reality is different.
- The top 10 official Docker images with more than 10 million downloads each contain at least 30 vulnerabilities.
- Among the top 10 most popular free certified docker images,50 percent have known vulnerabilities.
- 80% of developers don’t test their docker images during development.
- 50% of developers don’t scan their Docker images for vulnerabilities at all.
- 20% of the Docker images with vulnerability could have been solved by a simple image rebuild.
Some steps for providing better security
- Most base images have vulnerabilities so we should use very less base images because they can have vulnerabilities.
- There are many software to scan images so we should scan our docker images before running it.
- One container for one software/program. If in one container, we install so many software then it will have more vulnerabilities so for fewer vulnerabilities, we should keep one docker container for one software.
- Before pulling an image from the docker hub, we should make sure that the image is pushed by the genuine publisher and check the authenticity of the image and that image can be tempered.
- Don’t use the root user for running docker image. Instead of using the root user, create a dedicated user for running docker image.
- As part of your production pipeline, rebuild your docker files.
- Scan your Docker images as part of your development workflow and in your CI/CD pipelines. Scan your Docker images in your CI/CD pipelines and as part of your development workflow.
- Monitor your Docker containers in production by automatically scanning your base images and packages.
Conclusion
In this article we have learned about the vulnerabilities of docker, its type and how to secure our Docker container from it’s vulnerabilities. I have even discussed docker attacks and how do we protect our docker from such attacks and also through this article you all will learn why virtual machines are more secure than docker and in docker, we must do regular scans of images and containers because there are so many vulnerabilities and if not scanned on regular basis then it can cause attacks which will result as a security issue.
References:
- https://www.trendmicro.com/en_in/what-is/container-security.html
- https://docs.docker.com/engine/security/
- https://www.electricmonk.nl/log/2017/09/30/root-your-docker-host-in-10-seconds-for-fun-and-profit/
- https://www.trendmicro.com/en_in/what-is/container-security.html
- https://dl.acm.org/doi/10.1145/3029806.3029832
- https://snyk.io/blog/shifting-docker-security-left/
THANKS FOR READING.
ENJOY YOUR CODING!
