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

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 Promise and Reality of Cloud Security
Cloud security has been part of the cybersecurity conversation for years but has been on the sidelines for most enterprises. The shift to remote work during the COVID-19 pandemic and digital transformation projects have moved cloud infrastructure front-and-center as enterprises address the associated security risks. This report - a compilation of cutting-edge Black Hat research, in-depth Omdia analysis, and comprehensive Dark Reading reporting - explores how cloud security is rapidly evolving.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-25135
PUBLISHED: 2023-02-03
vBulletin before 5.6.9 PL1 allows an unauthenticated remote attacker to execute arbitrary code via a crafted HTTP request that triggers deserialization. This occurs because verify_serialized checks that a value is serialized by calling unserialize and then checking for errors. The fixed versions are...
CVE-2022-4634
PUBLISHED: 2023-02-03
All versions prior to Delta Electronic’s CNCSoft version 1.01.34 (running ScreenEditor versions 1.01.5 and prior) are vulnerable to a stack-based buffer overflow, which could allow an attacker to remotely execute arbitrary code.
CVE-2023-0123
PUBLISHED: 2023-02-03
Delta Electronics DOPSoft versions 4.00.16.22 and prior are vulnerable to a stack-based buffer overflow, which could allow an attacker to remotely execute arbitrary code when a malformed file is introduced to the software.
CVE-2023-0124
PUBLISHED: 2023-02-03
Delta Electronics DOPSoft versions 4.00.16.22 and prior are vulnerable to an out-of-bounds write, which could allow an attacker to remotely execute arbitrary code when a malformed file is introduced to the software.
CVE-2023-24613
PUBLISHED: 2023-02-03
The user interface of Array Networks AG Series and vxAG through 9.4.0.470 could allow a remote attacker to use the gdb tool to overwrite the backend function call stack after accessing the system with administrator privileges. A successful exploit could leverage this vulnerability in the backend bin...