Sponsored By

Containing Security

How to identify the appropriate security for your container-based virtual applications.

Rishi Bhargava

April 7, 2015

3 Min Read

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. 

About the Author(s)

Rishi Bhargava

Co-founder & VP, Marketing, Demisto

Rishi Bhargava is co-founder and vice president, marketing for Demisto, a cybersecurity startup with the mission to make security operations "faster, leaner and smarter." Prior to founding Demisto, he was vice president and general manager of the software defined datacenter group at Intel Security. A visionary and technology enthusiast, he was responsible for delivering Intel integrated security solutions for datacenters.

Before Intel, he was vice president of product management for datacenter and server security products at McAfee, now part of Intel Security. As an entrepreneur at McAfee, he launched multiple products to establish McAfee leadership in risk and compliance, virtualization, and cloud security. He joined McAfee by way of acquisition in 2009 (Solidcore, an enterprise security startup). At Solidcore, he was responsible for product management and strategy. As one of the early employees and member of the leadership team, he was instrumental in defining the company's product strategy and growing the business.

Rishi has over a dozen patents in the area of computer security. He holds a BS in computer science from Indian Institute of Technology, New Delhi and a Masters in computer science from University of Southern California, Los Angeles. He is passionate about new technologies and industry trends and serves as an active advisor to multiple startups in Silicon Valley and India.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights