This issue will track the task of replacing DCT in our build scripts
Issue
DCT is being deprecated in Docker.
Docker security has always been a nightmare -- to the point that it (by default) is 100% security theater on ephemeral CI runners here on GitHub.
Our solution to this was to (very terrible UX) set DOCKER_CONTENT_TRUST=1 and use rsync to manually pin the keys for the debian image layers we download with docker pull.
This had the effect of disabling TOFU. That's important because, if we don't pin the certificates manually with rsync, then docker would happily pull a malicious image (and the malicious singing keys at the same time, from mallory). By pinning the keys before ever running docker pull, that's the only way we can get docker to detect a malicious image (not signed by the key we expect) on an ephemeral build machine.
Unfortunately, I just discovered that the official docker documentation says that DCT is being deprecated. Apparently this was announced last year, and 4 days ago this blog post was published with advice:
Solution
The solution to this ticket is to figure out some way to update our build scripts so that we can verify the cryptographic integrity of all layers downloaded with a cryptographic signature that's pinned to a certificate stored in our repo.
We should test to confirm that docker pull:
- Will never TOFU any layer-signing keys, and
- If the signature isn't valid for the keys we've pinned, it exits with an error on
docker pull attempt
This issue will track the task of replacing DCT in our build scripts
Issue
DCT is being deprecated in Docker.
Docker security has always been a nightmare -- to the point that it (by default) is 100% security theater on ephemeral CI runners here on GitHub.
Our solution to this was to (very terrible UX) set
DOCKER_CONTENT_TRUST=1and use rsync to manually pin the keys for the debian image layers we download withdocker pull.This had the effect of disabling TOFU. That's important because, if we don't pin the certificates manually with rsync, then docker would happily pull a malicious image (and the malicious singing keys at the same time, from mallory). By pinning the keys before ever running
docker pull, that's the only way we can get docker to detect a malicious image (not signed by the key we expect) on an ephemeral build machine.Unfortunately, I just discovered that the official docker documentation says that DCT is being deprecated. Apparently this was announced last year, and 4 days ago this blog post was published with advice:
Solution
The solution to this ticket is to figure out some way to update our build scripts so that we can verify the cryptographic integrity of all layers downloaded with a cryptographic signature that's pinned to a certificate stored in our repo.
We should test to confirm that
docker pull:docker pullattempt