Abstract

Currently there are a lot of great technologies to sandbox and separate applications across powerful machines. However at times it can be difficult to choose the best way to go about doing that. In general, there are two paths to choose from: containers or virtual machines (VMs). Both paths have different benefits, concerns, and technologies that accompany them.

Technical Differences

The main technical difference between containers and virtual machines are that virtual machines are ‘real’ computers in a sense. They have their own hardware, operating system, file system, and kernel; it is just virtual. A container, on the other hand, does not have its own resources. Rather, it shares a kernel with the host, and is granted resources via the host’s kernel. This is slightly different than a VM platform allocating resources for a VM, because the VM will manage its allocated resources by itself while a container will not.

Virtual Machine overview

The concept of a VM is usually pretty simple to explain for those that do not already know what it is. It is a computer running entirely in software; it has a virtual processor with virtual RAM and virtual storage. All of these resources will eventually lead back to the hardware of course, but These resources are segregated from the host computer similar to how having multiple computers on the same network would be segregated from each other. This method of providing a sandbox for applications is quite secure, however, it is resource heave as you are running a new instance of an operating system with each VM. Additionally some software may take a performance hit or not work properly when run inside of a VM, depending on hardware and virtualization platform. The main benefits of running VMs is that there is much more separation between the host and guest OSs as well as each VM can be managed as easily as any other machine once set up.

Container overview

One of the major benefits of containers is the density. One gigabyte of RAM is enough to run a couple dozen containers or more. Running one dozen VMs on one gigabyte of RAM is impossible, let along a few dozen. The difference is that the segregation between the host and the container is not as good. It is much easier for an attacker to break out of a container than a VM because containers share a kernel with the host. Containerizing applications is perfectly sufficient for workstations and is even how most Android apps run. Containers can also make packages run more consistently on various systems, evidence of this is systems like Docker or Flatpak that can make applications run flawlessly regardless of which Linux distro the host is running. The issue with these systems are that the container images do not always contain packages that are up to date to assist the software’s comparability. This may be acceptable to some people on their workstation, however, this is almost never acceptable for a server, especially one running in a production environment. Other container systems, such as Linux Containers (LXC/LXD) do not necessarily have this particular issue as they function much more like lightweight virtual machines.

When to use which?

Obviously putting everything inside of separate VMs is the more secure way to operate, however, the resources to do that can quickly add up and with machine(s) will quickly be unable to operate. Additionally, some applications are recommended to be installed as containers of one type or another. Unfortunately, this is a decision that will ultimately have to be made on a case-by-case basis. If the application or service needs extra sandboxing, or will be publicly accessible then it should likely go in a VM. If an application is just operating internal services it will likely be alright inside of a container of some sort.

Compromising

A good compromise to this thought process is having virtual machines for containers that will contain similar types of applications. For example, one virtual machine might contain various web applications, while another VM will run various storage containers. These VMs can be categorized in a way that makes sense with the services that need to be run. This thought process is the way that QubesOS operates and becomes a “reasonably secure operating system”. It will use categorized of VMs that have various uses to sandbox what type of work is being done, rather than sandboxing each running application.