> There's a standards conversion going on where we can trace the provenance of each and every layer of the image, we can start signing those layers, and with that metadata, we can start doing automated decisioning, automated reporting, automated visibility into what's been done to that image at each step of the lifecycle.
Docker's CEO is being disingenuous. When you deploy a Docker container, you specify the image ID. The ID looks like a SHA-256 digest and even starts with the string 'sha256' but it is an arbitrary value generated by the docker daemon on the local machine. The ID is not a hash of the image contents [0, 1]. In other words, docker images are not content-addressed.
Since docker images are not content-addressed, your image registry and image transfer tools can subvert the security of your production systems. The fix is straightforward: make an image ID be the SHA-256 digest of the image contents, which is the same everywhere: on your build system, image registry, test system, and production hosts. This fix will increase supply chain security for all Docker users. It is massive low-hanging fruit.
Now Docker will add image signatures without first making images content-addressed. Their decision makes sense only if their goal is to make money and not make a secure product. I cannot trust a company with such priorities.
The fact that images are not content-addressed is very surprising to me. I just always assumed they were because… why wouldn’t they be? I bet a large proportion of other devs assumed the same.
That's because the parent comment is completely wrong.
Images have a reference (e.g. "ubuntu:20.04"), they have an ID inside docker (random string), and they have a digest.
All image data is stored by digest.
Even when you fetch an image reference it is looking up the digest of that reference and fetching that digest and that digest is verified.
An image manifest contains the digests of the image config and the digest of all the layers, the image config also stores the digest of all the layers.
This is how all the data is traversed from the registry.
A built (as in `docker build && docker run`) image does not have a digest because the digests are for the tar+gzipped versions of the layers (+ the image config and manifest).
The layers are not tar+gzipped until you attempt to push them, at which point the digest is calculated.
Docker's CEO is being disingenuous. When you deploy a Docker container, you specify the image ID. The ID looks like a SHA-256 digest and even starts with the string 'sha256' but it is an arbitrary value generated by the docker daemon on the local machine. The ID is not a hash of the image contents [0, 1]. In other words, docker images are not content-addressed.
Since docker images are not content-addressed, your image registry and image transfer tools can subvert the security of your production systems. The fix is straightforward: make an image ID be the SHA-256 digest of the image contents, which is the same everywhere: on your build system, image registry, test system, and production hosts. This fix will increase supply chain security for all Docker users. It is massive low-hanging fruit.
Now Docker will add image signatures without first making images content-addressed. Their decision makes sense only if their goal is to make money and not make a secure product. I cannot trust a company with such priorities.
[0] https://github.com/moby/moby/issues/39247#issuecomment-49697...
[1] https://github.com/distribution/distribution/issues/1662
EDIT: Added another link.