Telecom IQ
Showing results for 
Search instead for 
Did you mean: 

Comparison of Security Measures between Docker and Virtual Machines




Author: Tejas Gadaria, Systems/Software Engineer at HPE


Although Docker has been around for a pretty long time, a new set of use cases and deployment models have more recently pushed it into the limelight. Container methods, the technology underpinnings of Docker, were first implemented in 1979 with UNIX version 7. This can be thought of as the first instance of an “OS container”. Since then it has improved multifold. So why the massive recent interest in containers and Docker approaches for Linux?


 First: to understand Docker, we need to understand Containers.

In brief, Containers are the bunch of processes, isolated by Linux namespaces, with their resource utilization (CPU / Memory, etc.) controlled by Control Groups in a Linux kernel. Let’s talk a little bit about Namespaces and Control group.

Namespaces have an important role. Namespaces provide isolation between containers and also between a host and containers running on that host. Essentially, it wraps the set of system resources and presents them to the container’s processes, making the system resources look like they are dedicated to those processes.

Similarly, Control Groups is the important feature of Linux Kernel.  Control Groups control the isolation and usage of system resources (CPU / Memory, etc.). In Control Groups, each process belongs to a single node in the kernel subsystem hierarchy. Whenever you boot up your host machine, processes are considered to be running in node “1”. This means that even if you are not explicitly using Containers you are nevertheless implicitly running in a container with no resource limitations! J

When should I use Virtual Machines versus Docker Containers?

Deciding between these two technologies depends on the solution requirements. But first, let’s highlight a few distinguishing features of Virtual Machines (VMs) and Containers:


  • VMs are File System neutral.
  • VMs allow you to save data on a file system as well as mount volumes.
  • VMs provide good isolation of the host kernel, which is the most vulnerable part of the system. Hence, VMs are considered to be pretty secure when compared to Containers.
  • VMs consume lots of host CPU resources, since, in addition to running a full instance copy of an OS, it also emulates the hardware processes of the platform on which the VMs run.
  • VMs can run multiple applications on a single host/machine. (We are all doing this, It’s not good practice though)


  • Containers are made up of read-only file systems.
  • They are designed to support a single application.
  • Containers are ephemeral, so data can be stored in a host mount point or a data volume point.
  • Containers are very light weight, and can be spun up in milliseconds.
  • Containers have layered file systems that help to track very fine-grain changes in the images.

While Containers are making more and more sense from “Data Center best practices” and “Developer” points of view, VMs have (and will continue to have) their advantages. More generally, there will always be situations that require the use of both Containers and VMs. One area where Containers need further refinement is in the area of security.

Understanding Docker Container Security:

VMs are the heavyweight when it comes to security. Virtual Machines are trusted and widely accepted technology. In contrast, Containers are still not being used widely in production for various security reasons.

Process Isolation: with VMs, the hypervisor acts to some extent as a filter for guest VMs. In contrast, Containers share the same kernel where the host is running. This means:

  • A Container that is vulnerable to kernel exploits can make the entire host and any other Containers running on the host equally vulnerable. Correspondingly, if the kernel itself is vulnerable, that creates potential vulnerability for the host and all Containers running on the host.
  • Potential consequence: if one Container gains excessive access to certain resources (say, a result of a Denial-of-service attack), other Containers on that host can be starved.

Attack Surface: In comparison to Containers, VMs are thought to have a relatively large attack surface, though opinions on that point vary. 

  • Comparing to the Linux kernel, VMs need emulation and Virtualization drivers, which is not available by default in the Linux kernel. These capabilities must be provided with a large amount of additional code, which has the effect of increasing the VMs attack surface. In contrast, the container can be built from a single static binary without requiring an OS wrapper. The result: a significantly smaller attack surface.

Granularity of Control: Both VMs and Containers allow limits on resources (CPU, Memory, etc...) However, Containers provide tools that allow more granular control of those resources.

  • You can assign read / write permission to a particular file in a Container when the entire file system is read only.
  • Containers provide add and remove capabilities. E.g., by default, user “root” can perform only limited task inside the container by maintaining being UID 0.
  • Docker is working on “seccomp” capabilities, which filter out unnecessary system calls to kernel. This will provide even more granular control at various level and reduce the attack surface on the kernel.

Container Breakout: By default, Users are not ‘namespaced’. So, if an attacker gains access to a Container, host likely to be a victim of “privilege escalation attack”. Because any process breaks out of the Container, those process will have same privileges on the host as it did inside the container. [1]

Security Audit: an audit of a Container is much easier when compared to VMs.

  • VMs running in production most likely differ from each other, though they may have similar functionality. Also they tend to run multiple processes at a time. So you have to separately audit each VM. In contrast, Containers are running from base image, which means you can audit one image offline and, in the process, effectively verify hundreds of running Containers at once.


VMs and Containers differ on quite a few dimensions. However, I would say, think of Defense-in-Depth, add another layer of security and use containers. Use it with least privileges.


[1] Fedora do have user namespace enable in the kernel from fedora 21 onwards. RHEL is going to implement user namespace in the kernel from RHEL 7.2, but it won’t be available for the user. However, it is possible to enable user namespace in kernel, which will map the “root” to high UID on host system, but still, the file system is not aware of user namespace.


Visit us at our HPE website, and follow us on Twitter at @HPE_NFV and @HPE_CSP.

hpe.com_csp_nfv.png CSPResources.jpg NFVResources.png @hpe_csp.jpg @hpe_nfv.png


0 Kudos
About the Author


Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all