Name a tech company, any tech company, and they’re investing in containers. Google, of course. IBM, yes. Microsoft, check. But, just because containers are extremely popular, doesn’t mean virtual machines are out of date. They’re not.
Yes, containers can enable your company to pack a lot more applications into a single physical server than a virtual machine (VM) can. Container technologies, such as Docker, beat VMs at this part of the cloud or data-center game.
VMs take up a lot of system resources. Each VM runs not just a full copy of an operating system, but a virtual copy of all the hardware that the operating system needs to run. This quickly adds up to a lot of RAM and CPU cycles. In contrast, all that a container requires is enough of an operating system, supporting programs and libraries, and system resources to run a specific program.
What this means in practice is you can put two to three times as many as applications on a single server with containers than you can with a VM.
In addition, with containers you can create a portable, consistent operating environment for development, testing, and deployment. That’s a winning trifecta.
If that’s all there was to containers vs. virtual machines then I’d be writing an obituary for VMs. But, there’s a lot more to it than just how many apps you can put in a box.
The top problem, which often gets overlooked in today’s excitement about containers, is security. As Daniel Walsh, a security engineer at Red Hat who works mainly on Docker and containers puts it: Containers do not contain. Take Docker, for example, which uses libcontainers as its container technology. Libcontainers accesses five namespaces — Process, Network, Mount, Hostname, and Shared Memory — to work with Linux. That’s great as far as it goes, but there’s a lot of important Linux kernel subsystems outside the container.
These include all devices, SELinux, Cgroups and all file systems under /sys. This means if a user or application has superuser privileges within the container, the underlying operating system could, in theory, be cracked.
Now, there are many ways to secure Docker and other container technologies. For example, you can mount a /sys file system as read-only, force container processes to write only to container-specific file systems, and set up the network namespace so it only connects with a specified private intranet and so on. But, none of this is built in by default. It takes sweat to secure containers.
The basic rule is that you’ll need to treat containers the same way you would any server application. That is, as Walsh spells out:
Another security issue is that many people are releasing containerized applications. Now, some of those are worse than others. If, for example, you or your staff are inclined to be, shall we say, a little bit lazy, and install the first container that comes to hand, you may have brought a Trojan Horse into your server. You need to make your people understand they cannot simply download apps from the Internet like they do games for their smartphone.
Mind you they shouldn’t be downloading games willy-nilly either, but that’s a different kind of security problem!
OK, so if we can lick the security problem, containers will rule all, right? Well, no. You need to consider other container aspects.