Replacement for Docker Content Trust (DCT)
What do others use for ensuring the authenticity of images after downloading them with docker pull?
We’ve setup our CI build process to use docker for consistent, cross-platform builds. To ensure that our builds don’t use a malicious docker image (because the surface area of attack with TLS is enormous if you’re using X.509), we’ve been using DCT (Docker Content Trust).
Unfortunately, I just discovered that the official docker documentation says that DCT is being deprecated. Apparently this was announced last year, and in June this blog post was published with advice:
Cosign is not secure
We spent some time looking into cosign, but we discovered that the private keys aren't actually in the hands of the developer.
Rather, they use this complicated setup using very insecure X.509 to issue temporary certificates.
The result is that the OIDC identity provider (e.g., GitHub) extends the vector of attack significantly -- to probably tens of thousands of people -- that can publish a malicious image that will be accepted by cosign as "trusted"
Notation (Notary v2)
I also looked at Notation (aka “Notary v2”), but there’s no way to bootstrap the software safely, since (perplexingly) their tool for verifying the authenticity of images using cryptographic signatures itself can’t be verified using a cryptographic signature.
Alternatives
Are there any other alternatives that I can use to replace DCT to ensure the authenticity (using cryptography) of the container images that I download -- where the keys are actually held by the developer (thus significantly reducing the "insider threat" risk)?
What do you (or does your org do) to ensure that you’re not using maliciously-modified containers after pulling a new docker image?
9 replies
You should use the cross post feature in Lemmy, the two square overlapping in the default UI, you have made 14 posts so answers are going to be all over the place.
With a cross posted post it consolidates a lot of replies to one post.
Thanks. I assumed the client would figure it out automatically, but I guess that only works for links?
Is there a way to edit a post to indicate it's a cross-post?
Not sure of you can convert a text post to a cross post.
At the least you could add a link to one post to hopefully gather the answers.
I tend to build my own containers for anything that matters, but that might not be a viable option.
but how do you verify the sources of what you're fetching?
Is it coming from an unsigned git repo? That seems equally vulnerable..
If you are pulling a docker hub image you already trust the source code, the base image, and the built image.
Building from source means you only need to trust 2 of those things now.
You can mirror the repo to your own corporate forge and run tests to make sure things are OK but at some point you do have to trust someone.
With cryptographically signed images, you don't need to trust Docker Hub nor the source code nor the base image. You just verify the signature that could only have been made from the developer. You trust the private key and the developer only, which significantly reduces the vector of attack (publishing infrastructure, X.509, docker hub admins, etc) by magnitudes.
Unless I misunderstood your original question, you don't trust the Docker signing process, so getting a cryptographically signed image from there seems to fail your criteria.
You could build a Debian base image in-house from scratch if you wanted to and limit your tools to Debian only signed packages.
Ultimately you need to trust something.
For example, how do you trust the microcode updates to your CPU?
If the image is signed by the developer, you don't have to trust Docker (Hub) at all.
But how would I verify the source code? It would have to be signed.
It doesn't matter if it's the release image layer that's signed or the source (used to build the image layer) that's signed. Either would need to be crypographically signed by the developer.
Indeed. You need to trust something.
However, by using cryptographic signatures on release artifacts (eg container image layers), we can reduce that risk from having to trust tens of thousands of people to just one person.
That's a hugely meaningful reduction of risk.