Docker security is being given prime importance, considering the fact that the adoption and adaptation of Docker containers are consistently on the rise. Undoubtedly, there are a lot of works for ensuring utmost security for Docker containers and the latest releases of the Docker platform have a number of security-enabling features embedded.
In this section, we are going to describe where the Docker containers stand as far as the security imbroglio is concerned. As containers are being closely examined in synchronization with Virtual Machines (VMs), we will start with a few security-related points of VMs and containers. Let's start with understanding how VMs differ from containers. Typically, VMs are heavyweight and hence bloating, whereas containers are lightweight and hence, slim and sleek. The following table captures the renowned qualities of VMs and containers:
|
Virtual Machines |
Containers |
|
A few VMs run together on a single physical machine (low density). |
Tens of containers can run on a single physical machine or VM (high density). |
|
This ensures complete isolation of VMs for security. |
This enables the isolation at the process level and provides additional isolation using features, such as namespaces and cgroups. |
|
Each VM has its own OS and the physical resources managed by an underlying hypervisor. |
Containers share the same kernel with their Docker host. |
|
For networking, VMs can be linked to virtual or physical switches. Hypervisors have a buffer for I/O performance improvement, NIC bonding, and so on. |
Containers leverage standard IPC mechanisms, such as signals, pipes, sockets, and so on, for networking. Each container gets its own network stack. |
The following diagram illustrates how hypervisor-based virtualization enables the realization of VMs out of a physical machine:
The following diagram vividly conveys how containerization is distinguishably deviating from hypervisor-based virtualization:
The debate on the security side of VMs and containers is heating up. There are arguments and counter arguments in favor of one or the other. In the case of the virtualization paradigm, the hypervisors are the centralized and core controllers for the VMs. Any kind of access of freshly provisioned VMs needs to go through this hypervisor solution, which stands as a solid wall for any kind of unauthenticated, unauthorized, and unethical purposes. Therefore, the attack surface of a VM is smaller when compared to containers. The hypervisor has to be hacked or broken into in order to impact other VMs. This means that an attacker has to route an attack through both the VM kernel and the hypervisor before being able to touch the host kernel.
In contrast to the virtualization paradigm, the containers are placed directly on top of the kernel of the host system. This lean and mean architecture gives a very much higher efficiency because it completely eliminates the emulation layer of a hypervisor and also offers a much higher container density. However, unlike the VM paradigm, the container paradigm does not have many layers, so one can easily gain access to the host and other containers if any of the containers is compromised. Therefore, the attack surface of a container is larger when compared to VMs.
However, the designers of the Docker platform have given a due consideration to this security risk and designed the system to thwart most of the security risks. In the ensuing sections, we will discuss the security that is innately designed in the system, the solutions being prescribed to substantially enhance the container security, and the best practices and guidelines.