February 18, 2018

DevOps and containers are no longer cutting-edge concepts that will shape the future of how applications are developed, deployed, monitored and maintained. That ship has sailed. The future is now. Businesses that want to stay competitive need to be using containers, but along with that comes the unique challenge of trying to secure and protect a containerized application.

An application used to be a single thing. It may have run in a physical or virtual computer locally or from the cloud, but wherever it was it remained a single application to be monitored and managed. Containers break that application down into modular elements—abstracted from the underlying operating system—to provide greater agility, scalability and portability of the code.

The problem becomes, “How can you effectively secure and protect an application that may have elements running from different servers, which may also be written in different programming languages or hosted on different operating systems?”

The answer is, “Build security into the container itself.”

Typical Container Security

The question of securing and protecting containers is not new. There are plenty of potential—and sometimes very creative—solutions out there that attempt to tackle this problem. The typical approach to container security boils down primarily to solutions that rely on a kernel plugin or solutions that rely on privileged access. Both are solutions intended to provide better or more comprehensive visibility into the actions and behaviors of the containers at a broader system level.

Both of these approaches work to an extent, but they also both have inherent limitations that significantly restrict their functionality across a dynamic cloud environment. First of all, both are tied to the host—either kernel or root access—which means that the security solution itself is not seamlessly portable to other environments such as serverless computing or container-as-a-service (CaaS) platforms. In some cases, the privileged access approach also becomes a bottleneck and exposes the container environment to unnecessary risk.

Container-Native Approach

Matt Alderman, chief strategy and marketing officer for Layered Insight, provided some clarity around these issues facing container security—as well as a potential solution—in a recent blog post. What’s the solution? Embed the security in the container itself.

Alderman explains, “By adding security within the container to monitor network, storage and application calls, this approach does not require root privileges or access to the underlying infrastructure.”

This approach has no dependency on the underlying infrastructure. “It’s the only approach that provides infinite portability, as it supports all container environments, including CaaS and serverless computing. It also provides elastic scalability, as security moves with the container,” says Alderman.

Getting the Most Out of Containers

As I described above, the promise of containers is that they give developers and organizations greater agility, scalability and portability. You only realize half of those benefits if your container security solution requires kernel or root access. You can still scale within the environment where the container is, and that provides some amount of agility—but being shackled to a given host or platform takes away some of the agility and the portability aspects.

To get the most out of containers and access the full value proposition, you need to have an approach to container security that can match your containers in agility, scalability and portability. A container-native approach can secure and protect containers without placing artificial limits on the where and how those containers can be used.

Tony Bradley is a social media, community, and content marketing wizard--and also Editor-in-Chief of TechSpective. Tony has a passion for technology and gadgets--with a focus on Microsoft and security. He also loves spending time with his family and likes to think he enjoys reading and golf even though he never finds the time for either.