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.

(Source: Flickr)
(Source: Flickr)

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
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-36239
PUBLISHED: 2021-07-29
Jira Data Center, Jira Core Data Center, Jira Software Data Center from version 6.3.0 before 8.5.16, from 8.6.0 before 8.13.8, from 8.14.0 before 8.17.0 and Jira Service Management Data Center from version 2.0.2 before 4.5.16, from version 4.6.0 before 4.13.8, and from version 4.14.0 before 4.17.0 e...
CVE-2021-37578
PUBLISHED: 2021-07-29
Apache jUDDI uses several classes related to Java's Remote Method Invocation (RMI) which (as an extension to UDDI) provides an alternate transport for accessing UDDI services. RMI uses the default Java serialization mechanism to pass parameters in RMI invocations. A remote attacker can send a malic...
CVE-2021-23416
PUBLISHED: 2021-07-28
This affects all versions of package curly-bracket-parser. When used as a template library, it does not properly sanitize the user input.
CVE-2021-23417
PUBLISHED: 2021-07-28
All versions of package deepmergefn are vulnerable to Prototype Pollution via deepMerge function.
CVE-2021-23415
PUBLISHED: 2021-07-28
This affects the package elFinder.AspNet before 1.1.1. The user-controlled file name is not properly sanitized before it is used to create a file system path.