Containerization technology has been a game-changer, powering Docker and other transformative software solutions. It's also garnered its share of criticisms about performance, security, and resiliency.
But one of the creators of OpenVZ, a key containerization technology on Linux, is pushing back against what he feels are pervasive myths about containers -- many of which, he argues, are rooted in misunderstandings of how to use them and what they're for.
In a conversation, Parallels CTO James Bottomley noted that while many of the negatives come from people using containers, the same group sometimes carry expectations set by their experiences with hypervisors -- one of the technologies replaced in part by containers.
"Container technology is much more granular than hypervisors," Bottomley said, "and that makes containers much more difficult to set up securely. It's not deliberately negative; the enterprise is confused about how to use containers. Every time they run into a situation where they think they should be able to use containers and something goes wrong, there's usually something that comes out of it that says, 'Containers can't do this.'"
Further confusion stems from the links between different capabilities of container technologies in Linux and specific editions of the Linux kernel. "Only the most recent Linux kernels actually have all of the technology pieces necessary to build secure isolating containers," Bottomly pointed out. "If you start with a Linux kernel that's too old or a distribution with a kernel that's too old, you find that what's promised and what you can actually do are quite different."
The problems might not manifest for an engineer on her notebook running a bleeding-edge distribution, but they may be more of a issue for an IT manager using a stable (older) enterprise release in his data center. Many of the container features in use via the likes of Docker, Bottomley said, weren't introduced into the kernel until version 3.12 or 3.14.
The biggest myths about containers, Bottomley said, involve security -- notably, containers aren't secure enough. "It can be true if you set up your container wrongly, use a wrong kernel, or use a kernel from a distribution that didn't have the right security features like namespaces, since those more recent kernels aren't used by a lot of distributions in data centers."
In Bottomley's observations, many of the security problems arise from setting and reinforcing policies on both containers and their contents -- specifically, on the interface between the container and the host. "When you containerize any application," he said, "it still has to rely on operating system services. In this type of containerization, the OS is often running in a host virtualization environment, with the app in the guest's container. That boundary, which allows the guest container to call into the host OS environment, is where you get security problems if the policies are not sourced out correctly."
Bottomley is convinced that Linux container technology -- especially by way of Docker (which is not a container system, but a use of container systems) -- has sorted out the most egregious problems. "Docker isolates the namespace for processes [running within containers], and will eventually isolate the user namespaces," he said. "it doesn't do that currently, so that gives it a security problem if you actually run root inside the container. But that's fixable with user namespace isolation."
Bottomley notes, again, that many security issues hinge on the presence -- or absence -- of kernel-level containerization features and refers to the history of those features to explain the most common criticisms. "Docker started out on the 3.8 kernel," he noted, "and user namespaces [to provide additional security] weren't available in any form in Linux until 3.12. For about four kernel editions, they realistically had nothing they could use for security apart from what they rolled themselves."
To that end, per Bottomley, the biggest obstacles with containers can be traced back to the kernel -- itself a moving target. The problems that persist, like the inability to live-migrate memory in use by a container (a point raised by those running hypervisor-based solutions), will be addressed in future kernel features that make them possible.
[An earlier version of this article incorrectly identified Parallels, rather than OpenVZ, as the name of the product James Bottomley worked on.]