Last week I wrote an article explaining virtual machines and containers, and the pros and cons of the two. Today I want to focus specifically on containers and container security. Because containers share resources with the host and other containers on the host, they offer security risks that are not seen with virtual machines.

Application containers run on the same kernel as their host, meaning if the kernel is accessed through the container, it will affect every other container on the host, as well as the host itself. Virtual machines do not have this problem, since every individual VM, as well as their hypervisor, all have distinct kernels from the host and each other. 

Containers Docker, the most commonly used container engine, does not have users be namespaced by default, meaning a process will act the same way inside a container as its host. The problem is that a user with, for example, root privileges in a container will have those same privileges on the host, meaning a harmful process may potentially be injected into a container, and then escape into the host to compromise the machine.

Containers do offer a security benefit that is not seen on VMs, which is that they usually have a smaller vulnerability surface. What I mean by that is this: when you’re running a VM, you’re essentially working on a completely different machine with potentially a different operating system and library/binary files. And as any computer, it’s going to have fluff that isn’t always useful; code that’s just sitting there, waiting to be taken advantage of maliciously. With containers, the only dependencies that are used are the ones that are given in the container’s Dockerfile, restricting the amount of possible points of entry that a hacker can use.

All-in-all, although container technology does have its share of vulnerabilities, it’s important to remember that the cons of container security are very much outweighed by the pros of container functionality, and it’s good to know that containers seem to be progressing in a way that will help bring the IT field to its fullest potential.

In most areas of computing, the programmer will, at one point, have to test out the code they made. For small, isolated programs that only affect a specific part of a computer or OS, this can be done relatively easily without any fear. However, if a program is very large or important, or if hundreds of programs need to be tested simultaneously, risks to the host OS or machine may arise. The way one circumvents a problem like this is by setting up a new test environment for the program to run in that is isolated from the rest of the software so that no irreversible harm can come to it. There are main options for setting up a test environment.

There are main options for setting up a test environment. The first is by creating a virtual machine. A virtual machine is an isolated environment that is essentially its own operating system. Usually one would use Linux to set one up, and it will run as almost another instance of your computer. Several virtual machines can be set up using organisers, or “hypervisors”, and each instance has its own binary and library files. Only some files are allocated to the process, allowing the process to run independently from the rest of the system.

The problem with virtual machines, however, is that each instance takes up a lot of resources, more than is usually needed for the task. Code tested in one virtual machine may also not always translate perfectly into another OS. That is why the most popular form of isolated environments is called a container. Containers don’t require their own OS, several containers will run on the same engine. This way, they still give all the perks of an isolated environment, without the resource load, making them perfect for running hundreds or thousands of programs simultaneously. The most popular form of containers right now is the Docker engine, which runs on Linux systems. If you ever need to create a space where you need to test a piece of software that may be volatile or you think may contain a virus, it’s always good to set up a docker container so that nothing becomes compromised.