zhu difeng - Fotolia
By now, security professionals are familiar with virtualization given the significant adoption both in the data center, as well as in the cloud -- the use of virtualization is almost ubiquitous at many organizations. Practitioners more commonly encounter application containerization technologies in their organizations, which include Docker, rkt and the associated orchestration technologies like Kubernetes that surround them and help scale usage.
Practitioners are mandated to make technology risk decisions, and many of those decisions involve one or both of virtualization and containerization technologies. When comparing VMs vs. containers, it is natural to ask, which is more secure?
These tools are not equivalent, therefore a direct security comparison isn't an apples-to-apples comparison. In the case of VMs vs. containers for security, each requires a different tool set, an understanding of vastly different security models, and familiarity with an entirely different orchestration ecosystem. It also depends on the particular use case.
The salient questions become instead then: What security properties do each have? and How are they used in furtherance of security goals?" Some explanation -- and a deeper dive under the hood -- is advantageous to help practitioners consider how these tools fit into their organization's risk profile.
OS virtualization security
Between the virtual data center, hybrid cloud and IaaS, most technology and security practitioners have experience with OS virtualization. A key feature of OS virtualization is the strong segmentation boundary -- both between virtual hosts and between any given virtual host and the hypervisor.
Segmentation attacks can happen as numerous vulnerabilities demonstrate: Rowhammers, speculative execution vulnerabilities like Spectre or Meltdown and the occasional hypervisor-specific bug are the evidence. However, segmentation attacks in the wild are rare and the vulnerabilities hard to exploit.
OS virtualization helps in situations where a strong segmentation boundary is critical; for example, if security teams don't have control over the entire environment, like in a multi-tenant cloud environment. It can also be advantageous when teams need to make changes quickly to the underlying network configuration in the form of microsegmentation at the network layer, and when they want to migrate a physical device to a virtual environment.
There are some potential security downsides. Management issues may arise, particularly at scale. Issues such as undesired proliferation of images and sprawl, stale or outdated images in serialized form on disk, and inventorying challenges can cause headaches for security teams. Orchestration can lessen the consequences of these issues but cannot alleviate them entirely.
The ease with which developers and engineers can virtualize and migrate existing physical devices cuts both ways: Migrating these devices easily to a hypervisor will potentially bolster their security in the process, but in a poorly managed environment those same devices can translate to problematically configured hosts popping up in unexpected places and times in a given ecosystem. Over time, artifacts can collect on virtual images even in a highly disciplined environment; out-of-date operating systems, legacy middleware or old software libraries may be to blame.
Application containers, by contrast, have different properties, some of which bolster security and -- depending on usage -- some that can undermine it. A key property of containers is a more porous segmentation boundary relative to OS virtualization.
What does a more porous segmentation boundary entail? In an OS virtualization context, segmentation is enforced by the hypervisor below the level of the guest OS. The segmentation used by a container engine operates a different way. Containers run on the same OS instance as the container engine; they also run on the same OS as other containers. This is true even though containers can't normally interact with each other or with the container engine.
Containers use operating system features to create logical environments where views of processes, files and network state are invisible to each other. This is accomplished via namespaces. Resources are limited and usage in these environments is controlled. However, not everything is namespaced in the Linux world -- date and time are notable exceptions. To use date and time as an example, if security teams disabled the default protections that prevented a container from changing the time in most container engines, this would enable that container to change the time across the entire host, other containers included. Likewise, artifacts of the OS operate the same way they always did -- for example, the root user is still the root user. Segmentation potentially limits applicability for some situations. For example, a security team might decide against a high-security application in a multi-tenant situation.
That said, there can be potential security advantages depending on what you're trying to do -- just like with OS virtualization, there are pros, as well as cons. The use of containers fosters a mentality of old container elimination and subsequent redeployment. They aren't used long enough to develop personality. In the OS virtualization world, instances can live long enough to get stale: collecting backup files, old software artifacts and configuration tweaks are a few examples.
By contrast, a container will almost certainly be torn down and rebuilt when changes need to be made. This provides a security benefit. Beyond this, don't underestimate the security value that can be realized by allowing you to componentize application components or services that would otherwise be on the same virtual or physical device. This adds value to a broader, security-aware microservices-based deployment model.
The point is, to compare VMs vs. containers and ask "which is more secure" is a bit like asking "which is more useful: a hammer or a banana?" It depends entirely on the usage context. The banana makes for a better breakfast, but don't try to hammer in a nail with it.