Docker: With Content Trust, You Can Run Containers on Untrusted Networks
At DockerCon in June, Docker, Inc. introduced developers to Notary, its open source system for certifying the validity of the sources of Docker images pushed to public repositories, and encrypting the contents of those images. This morning, the company released its own branded implementation of Notary, called Docker Content Trust.
Docker’s aim is to deploy a signing and encryption system that’s so reliable on both the sending and receiving ends of the network, that the security of the network in-between is no longer an issue.
“One thing that we’re gaining is that we do not need to rely on any trusted means of communication,” said Docker security lead Diogo Mónica, in an interview with The New Stack, “for this content to be downloaded and verified securely by the final Docker user. This is essentially a huge guarantee now that we’re providing, that was not being provided before.”
Two Keys to Trust
Content Trust is, for all intents and purposes, Docker’s branded Notary. The basic framework in use is an open source project begun in 2009, called simply The Update Framework (TUF). Rather than a universal workflow for software updates, TUF is a workflow for update systems (and, in Notary’s case, repositories) that implement encryption, as a way of thwarting attacks.
One of the basic tenets of TUF is that no key used to encrypt files that are exchanged online should be stored anywhere where they may be made accessible online. Content Trust’s implementation of this principle will come by way of a two-tiered key system, which uses a per-repository key that addresses Docker repositories and is kept online, perhaps on a continuous integration system, separately from a root key that is used to create per-repository keys and is kept offline. Content Trust’s version of this implementation remains forthcoming, Mónica said in an interview with The New Stack.
“The root key can actually be saved inside of a USB key, stored in a safe, or in a bank — a secured storage location,” explains Mónica, “because it is only actually needed when you’re creating new repository keys.”
In a situation where a malicious actor attempts to inject a forged Docker image into a repository that utilizes Content Trust, the security chief continues, only the original publisher should have access to the key authorized to sign images for that repository. If that malicious actor attempts to inject an altered image at any point in the exchange with the repository, modifications to the file or to its signature will be detected as invalid.
Taking a cue from a suggestion made at DockerCon that InfoSec professionals want to see that green check-mark of assurance (a suggestion made by, oh, I don’t know, some reporter), that invalidity detection will turn the green “GO” stamp red when it appears next to the name of the image in the repository.
The key rotation process for per-repository keys happens quickly enough that malicious attempts to forge content using an old version of the key will also trigger invalidity. “Now you will actually get guarantees that the content is the latest content that you can get,” said Mónica, “because Docker Content Trust actually gives you guarantees on the freshness of the data. There actually are attacks where attackers essentially serve the users valid content, but that is old and stale. Content Trust allows you to resist these ‘freeze attacks.’”
Of course, all this assumes that malicious attackers never get a hold of both sets of keys. Isn’t some new form of key management tool necessary under these circumstances?
The fact that the root key is actually offline, Docker tells us, renders the question of key management software rather moot. What is it supposed to do, provide you with a reminder of what drawer or closet you left the root key in? That could be about as silly as a password maintainer that enables anyone claiming to be Scott M. Fulton, III, to retrieve his forgotten password by providing his grandfather’s name.
In a situation where a malicious actor does get a hold of a copy of a per-repository key — perhaps through the theft of a device where that key is stored — the physical root key, such as a Yubico FIDO key, may be used to generate a new per-repository key that automatically invalidates all earlier versions.
Baked In or Bolted On?
There continues to be considerable discussion, both in and outside of containerization circles, about the extent to which software developers should concern themselves with security matters. Historically, platform vendors have argued that if platforms do their jobs properly, developers need not concern themselves with security matters. On the other side of the fence is everyone who was burned by the Windows XP experience, and who has been too skeptical of Vista and its successors to follow Microsoft’s security guidelines.
The way distributed applications presently work in Docker reminds some people of their early experiences with systems such as DCOM, where program components trusted one another because the Registry told them to. In light of new discussions about the future of Docker networking, some are asking whether developers in the broader community will be tasked with the problem of defining a security architecture for Docker at the lowest levels.
For now, according to Docker Vice President of Marketing David Messina, the answer from Docker is no.
“For the developer, oftentimes in their workflow, security is sort of an afterthought,” says Messina. “In this case, they don’t have to think on security, but it is embedded in the model that we are delivering to them.”
Diogo Mónica emphasizes for us that, with respect to security, “the developer that is consuming this software does not think about it. They can build images, they can pull images, and they can continue operating normally, and not notice that it is Docker Content Trust that is actually validating all these signatures and doing all of these complex operations for them. From the point of view of the publisher, there will be a new concept, and that is essentially a function of this being a digital signature scheme that requires these keys to operate.”
Docker is a sponsor of The New Stack.
Feature image: “MMIX (Ten things you can do to improve your photography in 2009)” by Kevin Dooley. Released under Creative Commons CC BY 2.0.
