Containing Security

Virtual machines and containers are similar but distinct ways of virtualizing infrastructure to deploy applications. And they have similar but distinct needs for securing those applications.

Virtual machines are the most separate and secure method of virtualizing hardware, enforced by hardware. Each virtual machine is an instance of the whole operating system, providing all of the services and consuming all of the necessary resources. VMs talk to each other on the same hardware via network interfaces as if they were separate machines, and they have nothing in common except the bare hardware they run on. Hardware assists for virtualization further isolate the processor resources, physical memory, interrupt management, and data I/O between machine instances. Securing a virtual machine is like securing a physical machine. Security policies, firewalls, and intrusion detection and prevention all see each VM as a separate instance and are configured accordingly.

Containers are a hybrid between a single operating system and a virtual machine. Multiple containers run in a single instance of an operating system, but each has its own network stack, file space, and process stack. They also communicate with each other via network interfaces, but they do not yet have hardware assists for hardware-level isolation. With only one version of the operating system, the same hardware will support more containers than virtual machines -- two to five times as many or more, depending on the container requirements. However, containers can be granted additional privileges, accidentally or intentionally, that weaken the walls between containers as well as the underlying operating system.

One of the safest features of containers is running them without full root privilege. Applications running in containers should be fully functional without all of the powerful tools available as root privileges such as access to unrestricted disk, network, and process operations. This means that should some malware manage to modify itself to root level within a container, it does not have unrestricted access to the rest of the machine. Similarly, make sure that each container is spawned in its own root directory, without access to the hardware root directory. This restriction, however, is only effective if there are no privilege escalation vulnerabilities in the operating system or container base code.

Beware of Security Holes

Containers can be configured to expose and share ports and files directly with another container. This is a very useful tool for efficiently passing information between applications, but it opens up a potential security hole. A further recommendation for secure containers is to only run applications on the same machine that you would run without containers. Do not mix data types, privilege levels, or user namespaces across multiple containers on the same machine. Containers provide additional separation between applications and should be considered an additional security measure, not a replacement.

Virtualization enabled the cloud-computing revolution. The fact that these environments are isolated at the hardware level creates the perfect environment for multitenant scenarios. Sensitive workloads from two different customers can be running on the same hardware without any compliance or security compromise, keeping customers comfortable with cloud deployments.

Containers do not currently provide this level of isolation. The weaker separation between containers creates security and compliance challenges when running workloads from different customers. As a result, it is vital to understand the security implications if you are using containers for multitenant scenarios.

The increasing use of containers and other software-defined virtualization tools continues to increase the agility of data center operations. Security configuration and management now needs to match that agility, demonstrating the emerging need for software-defined security, which I will cover in more detail in the next post.