What’s in a container? You don’t know. And that’s a problem

How much do you really know about application containers? Not the technical features or benefits, as those are readily circulating across technology communities. From extreme application portability and flexibility to simplified IT operations, application containers appear to be god’s gift to IT. But, again, ask the question: What do you really know about application containers? Specifically, your application containers?

An application packaging and delivery technology, Linux (application) containers isolate applications from all but the needed components of a host operating system, enabling applications to be easily developed and deployed across multiple systems. Built from open source technologies, including CGroups and SELinux, containers themselves include many different pieces, not all of which are readily transparent or accessible to the consumer. Add that to the fact that many containers come from vendors that don’t maintain or support the software that is included, and application containers rapidly move from “download and run” to, “Wait a minute, what’s in this thing?”

Background checks required

To help answer that all important question, IT needs to first know the provenance, or origin, of a container. Containerized applications from a known and trusted source, like an established independent software vendor or developer, are more likely to be built with stability and security in mind than those created by a shop that is more concerned with just “churning out code.” Containers built by a trusted source are also more likely to have other inherent values, like a clear and concise manifest or “packing list” that details exactly what is in the container, whereas other containers may come with no content listing or a dubious (at best) description of the containerized application. The most thorough “packing list” will also explain from where the contents came, when and where they passed though others hands, and what versions are included. Not unlike an international shipping manifest, the container will assert that the contents have not been tampered with through the delivery process.

Handle with care

Contrary to what you may read or hear, containers do require some level of maintenance.

Containers are not intended to be deployed and left alone. Just like any other application stack, they require updating (or wholesale replacing) with fixes for everything from security flaws to stability issues. End users may not know when such a fix is needed or, if they do, may not know where to find a fix or how it should be applied to their environment. Even though the container may come from a trusted source, without a notification system in place and guidance on how to apply the fix, an IT shop could easily end up running a compromised application container without knowing it, essentially throwing up a “welcome mat” for would-be digital interlopers.

This end up

The last component needed to determine what’s in the container is certification, something that is currently lacking in the container ecosystem today. Beyond coming from a trusted source and including some kind of maintenance agreement, containers should be verified to work on a given host. Especially if it’s a production system, certification entails support, so in the event that something unforeseen happens with a certified container on a critical system, the developer or provider will be on tap to help resolve the issue.

If you’re thinking “Hey, these answers are what most IT shops require from standard application vendors today,” then you’re right. Just because containers are new(ish) and deliver delightful benefits, they don’t get a pass when it comes to trust, maintenance, and support. They are ultimately still application stacks, many of which will be mission-critical, and will be running on production systems.

That’s why we need to remember that when asking, “What’s in the container?” the answer is an application stack. And just like any other application stack, would a reputable IT shop deploy an untrusted, orphaned and unsupported application stack onto a production system? Um, no.

Answering this question should be paramount for vendors entering the container space. It’s still an application, just in a fancy box, so treat it like one.

Lars Herrmann is senior director of strategy at Red Hat.