X
Innovation

​Docker 1.8 adds serious container security

The new open-source Docker container release has numerous new features, but the headline news is its improved security.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

Server and cloud developers love Docker and containers, but they're also more than a little worried about container security. Now, in its latest release, Docker 1.8, Docker is tackling the problem head on with Docker Content Trust (DCT).

docker-content-trust.png
By digitally signing container images, Docker will make it much harder to hacker Docker containers.
In an interview, Diogo Mónica, Docker's security lead, told ZDNet, "With Docker Content Trust, developers and administrators have an easy to use security solution. It's baked into Docker so they can use it without requiring them to learn much new." Further, "once it's enabled, Docker will only work with trusted data and images."

Mónica explained:

Docker's central commands 'push,' 'pull, 'build.' 'create,' and 'run' will only operate on images that either have content signatures or explicit content hashes. The result is that IT operations teams have the assurance that only signed content is being used in their production infrastructure. Leveraging this implementation of content trust, Docker will be signing the Docker Hub Official Repos, providing users with a trusted set of base images they can use to build distributed applications.

DCT uses a public key infrastructure (PKI) approach. The security program has two distinct keys: An off-line (root) key and a Tagging (per-repository) key that are generated and stored client-side the first time a publisher pushes an image. Each repository has its own unique tagging key, which allows the holder to digitally sign Docker images for a particular repository. The tagging key is used any time new content is added or removed from the repository. Because the tagging key is online, it's vulnerable to administrators being compromised. With DCT, the publisher will be able to block content with compromised keys by using the off-line key, which must be securely stored off-line.

The program also generates a Timestamp key that provides protection against replay attacks. This blocks attackers from trying to get you to run signed but expired content. So, Mónica said, if someone tried to get you to run a stale application with known vulnerablities, properly implemented DCT will still protect you.

For now, Docker manages the Timestamp key. The company claims that this reduces the hassle of having to constantly refresh the content client-side.

To make this work, DCT uses Notary. This is a Docker open-source project, which is designed to serve as "infrastructure plumbing" for secure and trusted content distribution. An enterprise with its own private registry or third-party solutions can integrate with Notary to have its repositories work with DCT.

Notary, itself, is built on The Update Framework (TUF). This is a security framework for software updates. At its heart TUF uses a variety of cryptographic keys for content signing and verification. TUF was built to allow the resistance against a variety of different classes of attacks. By default TUF uses the the RSA Probabilistic signature scheme (RSASSA-PSS) and the Elliptic curve digital signature algorithm based on Twisted Edward curves (ed25519).

DCT is built into Docker Engine 1.8, so you can start using it immediately. If you're using Docker for production, I highly recommend you start using DCT.

Docker 1.8 also includes the following new features:

Docker Toolbox: New developer installer for Mac OS X and Windows.

Docker backend storage support: Docker volumes can now be backed by third-party storage systems. There are plug-ins available from ecosystem partners such as Blockbridge, Ceph, ClusterHQ, EMC, and Portworx.

Docker Registry 2.1: This provides faster and more secure image pulls. It also lets you list your repositories through the application programming interface (API) and in addition to Amazon S3 and Azure, images can now be stored in OpenStack Swift, Ceph Rados, and Aliyun OSS.

Related Stories:

Editorial standards