4 ms·
> 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 th
by mleonhard 5y ago
> 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.
[0] https://github.com/moby/moby/issues/39247#issuecomment-496971248 https://github.com/moby/moby/issues/39247#issuecomment-49697...
[1] https://github.com/distribution/distribution/issues/1662 https://github.com/distribution/distribution/issues/1662
EDIT: Added another link.
- bspammer 5y agoThe 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.
- voxic11 5y agoThey are if you use the digest rather than the id.
- mleonhard 5y agoYou can specify the digest of a base image when building a new image. You cannot specify the digest of a built image when starting a container.
- cpuguy83 5y agoA 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.
- hda111 5y agoPodman project recently introduced a lot of content addressing features. Some are still experimental though.
- cpuguy83 5y agoThat'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.
- cpuguy83 5y agoI will add, once the image is on disk indeed the integrity is not verified so it can be modified after pull either maliciously or by accident. Once pulled, the content addressed layers are extracted into the storage driver (overlay, btrfs, whatever).
- voxic11 5y agoYou seem to be mixing up image ids which are not content addressable identifiers and image digests which are.
- mleonhard 5y agoImage IDs are not content addressable identifiers and I need them to be. How is that a mixup?