Docker, Twistlock, CoreOS, and the state of container security

Cryptographic hardware keys, inspecting for flawed software, and end-to-end trust add up to secure containers

When Docker turned container technology into a commodity, one question immediately sprung up: "What can we do with them?" With that query out of the way, a much larger one looms: "How do we keep them secure?"

After that inquiry, a horde of others follow. What does "secure" mean in this context? Are you securing access to the container or checking to make sure what's inside it is valid? What do you do about software already inside a container that might be riddled with security issues?

With current container technology moving away from dependency on a single vendor and more toward an open ecosystem -- especially regarding security -- it's unlikely any one solution will deal with these issues. Instead, we're seeing a panoply of answers to the different container security questions.

Security starts at home

Docker always has plans for moving container technology forward, security included. At DockerCon Europe in November, the company announced several major security advancements.

Biggest among them was support for user namespaces -- Docker containers no longer have to run in a privileged account to get things done. Docker also will allow containers to be signed by Yubico hardware keys, which verify both where a container came from and what it holds. Plus, containers hosted in Docker's official repository can be scanned for known vulnerabilities.

Impressive as this is, others are stepping up to execute on many of the same ideas or entirely new ones. They should -- competition helps defray worries about Docker's solutions being the automatic default.

Insecure inside

If you're about to deploy a container into production, especially one built with third-party software, you'll want to know if anything inside has a known security issue -- or if a detail previously thought harmless later develops into a security risk.

Twistlock was created to scan containers for known problems by checking the software inside against the CVE database. In addition, it checks the environment around the container -- for example, disconnecting it from the network if it's not supposed to be linked in the first place.

Google Cloud Platform now offers Twistlock for containers hosted there or stored in its container registry, although a local container repository can also be scanned.

Keep the core safe

CoreOS has long advocated for containers, but it's also critical of Docker's approach, especially regarding security. Thus, it spun off its own container format and runtime which it claims puts security first.

Previously, CoreOS announced tooling and support for the kind of vulnerability scanning Twistlock offers. More recently, it announced a more ambitious form of end-to-end security, called Distributed Trusted Computing, as part of its enterprise-level Tectonic product.

Like Docker's Yubikey product, Distributed Trust Computing uses hardware-level trust -- keys in the user's system's firmware and Trusted Platform Module -- to guarantee that containers have not been modified. It also further ensures that the system itself, which runs CoreOS's container-delivering operating system, is intact and only containers approved by you can be launched.

The folks at CoreOS seem to understand how tough it is to get end-to-end security right, and they've assigned smart people to the job. A co-creator of this scheme, Matthew Garrett, principal security engineer at CoreOS, is the same Matthew Garrett who designed a method of running Linux on Windows 8 PCs outfitted with Microsoft's proprietary Secure Boot UEFI technology.

Copyright © 2015 IDG Communications, Inc.