Open dnoliver opened 3 years ago
Moving this issue over to the docker repo. Looks like we need to investigate how to sign official releases.
Details look to be here: https://docs.docker.com/engine/security/trust/#signing-images-with-docker-content-trust
so what extra does this give us ? It's not as if just anyone can push to the repo/docker hub. And how does it compare to full official docker images ? (https://docs.docker.com/docker-hub/official_images/) - does it really add that much value (vs maintenance effort)
Having Docker Content Trust enabled is recommended by docker-bench-security and the Center for Internet Security (CIS) Docker Benchmark. So anybody following those guidelines will run into this problem with an unsigned image.
Even if anyone can push to the repo/docker hub (I guess it is password protected at least?), only the ones that have the private key can generate signed images, or sign them after being pushed. I guess there are much more requirements than signing images to became an official image (like having Docker's approval to became one), but signatures can be managed independently by any user or organization.
In addition of having a way of verifying the source and integrity of the image on pull and run, Docker Content Trust follows the recommendations provided by The Update Framework, so the mayor benefits for the users of this image is having a reliable update process. Having to disable that feature to use one image is a major drawback.
As regards implementation effort, there are automation examples of this process like in here
Pushing this back from the v2.0 release as I still can't work out how to sign a multi-arch container build from the docker build-push GitHub Action
Still can't find any sensible way to sign multi arch builds from docker buildx
What are the steps to reproduce?
What happens?
What do you expect to happen?
Please tell us about your environment:
Workaround: