Containers have arrived — and no one knows how to secure them

Very likely this year or next, your company will be running applications on a combination of on-premise, hybrid, cloud, virtual, and container solutions. Your company might be running containers already and you don’t know about it.

If you thought trying to understand and secure clouds was tough, containers add another set of complexities. InfoWorld has been covering Docker containers (and their emerging rivals) since their inception, but in my experience, most computer security people don’t understand them.

Containers in a nutshell

Containers are an attempt to abstract applications from the underlying OS to enable faster development and easier deployment. You can run any software in a container without going through the usual installation rigmarole, vastly increasing agility. And unlike virtual machines, containers execute directly on the host OS, sharing the kernel with other containers.  

Docker kicked off the container trend by standardizing the packaging and APIs for Linux containers, which draw on resource controls and namespace isolation provided by the Linux kernel. Even Microsoft is getting in the game, promising support for Docker containers along with native Windows Server and Hyper-V containers in Windows Server 2016.

Containers require that the underlying host operating system run a container interface and hosting engine — in Docker’s case, the Docker Engine. Developers and admins can interface with the Docker environment using the docker.exe client or develop their own interfaces using an API.

Securing containers

Making sure containers are run securely involves understanding all the various parts and components, and making sure each one is securely configured.

At the very least, everything you’ve learned about securing physical and virtual machines applies, as containers may run on either. Virtual machines have every vulnerability you’ll find on a physical machine, plus VM-only (known broadly as guest-to-guest, guest-to-host, and host-to-guest) vulnerabilities. You have to make sure the underlying OS is patched and securely configured. That’s a given. You have to worry about traditional application security as well; even though an application is hosted in a container, nothing has changed.

But we should be concerned about new container-only vulnerabilities. The container architecture, despite what some supporters will tell you, isn’t simple. And complexity is the enemy of good security. Unfortunately, there is no hardware-based hypervisor layer or TPM-like chip specialized for containers to handle the heavy security lifting. It’s all bits of software interacting with other movable and portable bits of software. It’s a recipe for discovering new vulnerabilities. In my opinion, the Docker ecosystem makes Java’s ultrapenetrable environment look tame in comparison.

I couldn’t begin to cover the container-only stuff you need to be worried about in a short column. Serdar Yegulalp said it best in his recent InfoWorld article on Docker’s new security benchmark:

The benchmark, a 118-page document available as a free download, describes a set of best practices for deploying Docker containers in production. All told, there are 84 best practices, along with a checklist summarizing them all, and they range from the obvious (don’t let untrusted users run the Docker daemon) to the less obvious (run a local registry mirror to reduce network traffic).

The newly published benchmark focuses on securing Docker and containers in a Linux-only environment, but many of its lessons and recommendations can be applied to Windows or other containerized environments. Almost everything it recommends is basic common sense and applies to any normal, noncontainerized install. As excellent as this document is, it doesn’t cover any of the special interactions and potential vulnerabilities that containers and container engines are bound to have.

As a computer security professional, I’m waiting for a guide in which the container environment itself is analyzed, threat modeled, and penetration tested. Though that sort of analysis won’t find everything, at least it will uncover basic issues we’ll all face with containerization. For example, I can guarantee you that an enterprising hacker will find a way to create container-to-container, container-to-host, and host-container vulnerabilities, similar to what we see in the virtual machine world.

More or less secure?

Beware the false prophets. You will probably read articles from supposed experts claiming containers’ additional separation from the underlying OS and built-in container engine controls will strengthen security and make it easier.

We heard the same bogus arguments from the VM crowd. In reality, when we run a new breakthrough on top of old technology, we simply have to learn more — which adds to, not replaces, previous concerns. Our job never gets easier. In fact, some of the easy topics become harder.

Some are already asking excellent security questions. In response to the Docker security paper, one commenter asked how a task as routine and mundane as patching an underlying operating system will be handled with containers. All of the proposed answers involve either additional efforts beyond traditional patching or a trade-off that compromises versioning control (which most developers wouldn’t allow). You can bet the eventual answer will not be less patching or effort, though I’m sure some will claim less effort is required in certain edge-deployment scenarios (such as a highly restricted OS or kernel).

I’m not going out on a limb in asserting that containerization will add complexity to our already Byzantine security world. You can’t stop containers any more than you can stop the cloud wave.

At some point, if you want to remain relevant, you’ll have to bite the bullet, climb onboard, and learn what it will take to secure containers — in a world that hasn’t yet figured out how to secure them. Get ready for the ride.