Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Security Management //

Cloud

6/21/2018
08:05 AM
Alan
 Zeichick
Alan Zeichick
Alan Zeichick
50%
50%

Containers in the Cloud Are Great, but Are They Secure?

Containers are an efficient means to package, deploy and run software in the cloud. There are legitimate security concerns, however.

Ever since they burst onto the scene, containers have been legitimately hailed as a very efficient means to deploy applications onto servers. Containers, such as those based on the Docker open-source standards, consume fewer resources than virtual machines, and containers are easier to design and faster to instantiate and provision.

Unlike VMs, however, containers aren't 100% isolated from the underlying host operating system, which is most commonly Linux or Window Server, or from drivers or other applications on the server.

Consider VMs, which are an older technology.

A VM is a complete virtualized server that's assigned disk space, processor cycles, and I/O resources by software called a hypervisor. Within the VM are everything you'd find on real server: An operating system, device drivers, applications, configuration files and network connections.

In other words, you've got a stack that -- from the bottom up -- is the bare metal, the server's host operating system, the hypervisor, and then one or more virtual machines, each with its own operating system, drivers and applications.

By contrast, everything in a container shares the underlying host operating system, device drivers and some configuration files. Instead of a hypervisor, there's a Docker Daemon -- if you’re using Docker, the most popular containerization system -- which provisions one or more containers. Each container only holds applications. Those applications rely upon the host operating system and drivers, which it also shares with other containers running on the same server.

The container benefit: lighter weight
If you have 20 Linux virtual machines on a Linux server, you're using memory and CPU resources to run 21 instances of Linux -- 20 for the VMs, and one for the host. It takes time to start up all those Linux instances, and you're wasting a lot of resources on overhead.

On the other hand, all those Linux VMs are isolated from each other -- in fact, they could even be different versions of Linux. In the VM model, that’s totally fine.

If you have 20 containers on a Linux server, by contrast, you only have one copy of Linux running. Startup up a container is very fast, and consumes far fewer resources. There's only one Linux kernel, and one set of shared libraries.

However, it is possible for security problems in one container to leak out and affect other containers or their applications.

The VM benefit: stronger isolation
To get geeky for a minute: Technology in modern microprocessors, host operating systems (Linux and Windows), and hypervisors (VMware ESX, Citrix XenServer, and Microsoft Hyper-V) provide hardware-based isolation between each virtual machine. That protection is in concentric rings: Each ring is protected from a higher-numbered ring, with Ring 0 in the center, walled off from applications.

In a virtual machine system, the host operating system's kernel runs in Protection Ring 0 -- which means nothing can get to it. The hypervisor runs in Ring 1. Individual virtual machines run in Ring 2 -- and thus, can't get to the hypervisor inside Ring 1, or to the operation system either.

What's more, the hypervisor can use its Ring 1 privileges to enforce rules preventing one VM from accessing another VM's memory, applications or resources.

Things aren't equally secure in the container world, since the Docker Daemon isn't a Ring 1 hypervisor, but rather, is simply a Ring 2 application. There's nothing in the hardware, therefore, that can completely block one container from making changes to the underlying server, or from accessing other containers’ memory, storage, or settings. There are software protections, yes, but they’re not impenetrable.

How to secure containers
The security in a container-based server should be considered -- in my opinion -- as appropriate for "friends and family": You should know and trust all the applications running in containers on that server.

Yet you don't need to know or trust the applications running in other virtual machines on the server, which is why cloud hosting companies use VMs, not containers, to isolate customers' software and data.


Now entering its fifth year, the 2020 Vision Executive Summit is an exclusive meeting of global CSP executives focused on navigating the disruptive forces at work in telecom today. Join us in Lisbon on December 4-6 to meet with fellow experts as we define the future of next-gen communications and how to make it profitable.

There are ways to harden containers to make them less vulnerable, but they come down to a few common approaches. First, tighten the attack surface of the containerized software so that if it is attacked, there's minimal danger of data leakage.

Another is strict control access to containers, and if necessary, isolate particularly sensitive containers on their own servers.

Be sure to research the container system that you're using, and the underlying host operating system. For example, those running containers on Red Hat Linux should look at the company’s "Ten Layers of Container Security " document. Other must-reads are Docker's "Introduction to Container Security " and Microsoft's "Securing Docker Containers in Azure Container Service."

Containers are the fastest, most efficient way to deploy applications into the cloud -- and are much more resource-efficient than virtual machines. The trade-off is that containers aren't as secure as virtual machines. Use containers with that in mind, and you'll be fine.

Related posts:

Alan Zeichick is principal analyst at Camden Associates, a technology consultancy in Phoenix, Arizona, specializing in enterprise networking, cybersecurity, and software development. Follow him @zeichick.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/14/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 New Cybersecurity Vulnerabilities That Could Put Your Enterprise at Risk
In this Dark Reading Tech Digest, we look at the ways security researchers and ethical hackers find critical vulnerabilities and offer insights into how you can fix them before attackers can exploit them.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17475
PUBLISHED: 2020-08-14
Lack of authentication in the network relays used in MEGVII Koala 2.9.1-c3s allows attackers to grant physical access to anyone by sending packet data to UDP port 5000.
CVE-2020-0255
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2020-10751. Reason: This candidate is a duplicate of CVE-2020-10751. Notes: All CVE users should reference CVE-2020-10751 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-14353
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-18270. Reason: This candidate is a duplicate of CVE-2017-18270. Notes: All CVE users should reference CVE-2017-18270 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-17464
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2020-17473
PUBLISHED: 2020-08-14
Lack of mutual authentication in ZKTeco FaceDepot 7B 1.0.213 and ZKBiosecurity Server 1.0.0_20190723 allows an attacker to obtain a long-lasting token by impersonating the server.