Docker Applies Secure Key Model On Code HandlingDocker Applies Secure Key Model On Code Handling

7 Worst Cloud Compliance Nightmares

Docker Platform release 1.8 is now available, and its centerpiece is an enhanced security system known as Docker Content Trust for managing software updates in containers.

Containers have a lot of code replacement going on to enable updates to a service or application running in a remote location that's reachable via its known Docker container location and formatting. If an identifiable code segment (or segments) gets updated inside the container, the rest of the application continues running as before.

But who vouches for the integrity of the code added to what may be a production application? In the past, the process of executing updates by many different vendors was replete with security holes. A study of 10 frequently used update packages by the University of Arizona in 2008 found all 10 subject to exposures that could compromise a production application. Slashdot reported the study with the headline, "Package Managers as Achilles Heel."

[Want to learn more about Docker security? See Docker To Defang Root Privilege Access.]

As recently as January 2015, Jack Edge, writing in Linux Weekly News, found the "verified" copy of Ubuntu being loaded into his Docker container may not have been verified at all. He concluded that he could have been given a spoofed version of Ubuntu with vulnerabilities.

To defend against this issue, Docker has built The Update Framework's (TUF) double-key approach to security into its container operations. TUF also happens to be the recommended security measure that Docker rival CoreOS included in its proposed App Container specification. TUF is derived from work under a National Science Foundation grant, and has been verified by the NCC Group's Cryptography Services Team (formerly the British National Computing Centre).

"We looked around and found the most stringent standard of content security out there," said Diogo Monica, security lead for Docker Inc., the company behind the open source Docker container formatting system.

The TUF system imposes a digital signature on code that verifies its originating source as it moves from a recognized repository to an organization's Docker. A signed image of Ubuntu coming from an Ubuntu repository would be a verified copy, good for production use, said Monica, who previously built security at payments system supplier Square.

TUF requires that a verified copy have "a fresh guarantee," he said. It has to be a recently issued copy of the image, not an older image masquerading as the code supplier's most recently issued image. Suppliers are not in the habit of mislabeling their code, but a man-in-the-middle attack would seek to compromise a repository server, confiscate the code's digital signature, and issue vulnerable code under its imprimatur.

The TUF specification provides a recovery mechanism, a root key that is held offline by the code supplier on a secure server, in the event the repository key is compromised. With the root key, a new per-repository key can be set and the repository's integrity restored. Some popular package-management systems today do not have a recovery mechanism, Monica explained. If their original per-repository key is compromised, code may continue to be issued under its digital signature, and only a public alert and warnings stand between its continued use and its discontinuance. Members of the user community who don't see the warning may become unwitting adopters of damaged code.

Under Docker Platform release 1.8, code images signed with a per-repository key will represent trusted content that can be distributed to a Docker-based system anywhere. Docker Engine and Docker hub will work with Docker Content Trust (DCT), provided the Docker client users have opted into DCT by notifying the Docker Platform daemon that they wish to do so.

At a future date, Monica explained, DCT will be a default way of working with the Docker Platform. As a new service, Docker wants its customers to be aware of DCT provisions and voluntarily opt in so they understand how their platform now works.

"We've leap-frogged the status quo" of implementing software package updates, he said. If a digital key is stolen in an older package-delivery system, "you're toast. There's no way that key can be rotated out of use or replaced." With DCT, it might become a best practice for per-repository keys to periodically be reset with a new key by the owner of root-key privileges. That way, if the repository were compromised, the compromise would have a definite (and hopefully short) shelf life.

"When you use Docker Content Trust, you can't get an old image" of code containing hidden vulnerabilities known to a malicious attacker. Known weaknesses in security were one reason Docker first launched its platform with the warning that Docker wasn't yet recommended by the company for production use. DCT makes that warning a piece of ancient history in the Docker story. Now the customer base needs to become familiar with and use it.