Is there a way to verify the integrity of the docker image. I know Inductive publishes a sha256 on its digest on Dockerhub but this doesn’t match the image ID within Kubernetes or docker images digest.
As per The Challenges of Uniquely Identifying Your Images, it seems that we can only find the image ID as the sha256 calculation of a json file within the docker image, but this doesn’t verify what is on Dockerhub matches with what we are running.
You’re on the right track. When you do something like a docker image inspect <some image>
, the ID
is the digest of the config JSON for the image. This isn’t found on Docker Hub, as only the digests of the image manifest list and image manifests are shown there. See the diagram below against inductiveautomation/ignition:8.1.19
as an example:
So, when you do something like docker pull inductiveautomation/ignition:8.1.19
, what you’re doing, in essence, is reaching out and retrieving the manifest list that contains manifests for each of the available OS/architecture platforms. In the case of Ignition, this is linux/amd64
, linux/arm64
, and linux/arm/v7
. These manifest lists contain checksums for each of the manifest’s.
If you’re on linux/amd64
, you’ll then proceed to pull the associated manifest, which will contain information about the config JSON (this is the image ID that you see with your image once you’ve pulled it) as well as the associated filesystem layers that make it up. All of those resources also have checksums in that manifest.
Here you now start pulling all of those blobs and validating against the checksums from the manifest. If something gets modified from those definitions (such as in transit, or in the layer data on the remote disk), the pull will fail with either a filesystem layer verification failed
or manifest verification failed for digest
message.
So, ultimately, if you want to make sure you retrieve a specific image version, use the explicit checksum instead of just the image tag–this makes sure that you’ll always get that image (and its associated pieces).
# So instead of pulling like this:
$ docker pull inductiveautomation/ignition:8.1.19
# ... you can use the explicit checksum from the manifest for your platform, i.e. `linux/amd64`
$ docker pull inductiveautomation/ignition@sha256:f3c23e8ea52564a4d8807d7824db1ccf4e8f8220e14cbaba94780992e0ae3dee
# ... and then tag it yourself
$ docker image tag inductiveautomation/ignition@sha256:f3c23e8ea52564a4d8807d7824db1ccf4e8f8220e14cbaba94780992e0ae3dee inductiveautomation/ignition:8.1.1
9
The other answer (which is on our roadmap) is to enable something like Content Trust to make the process of pulling only trusted images/tags “just work”.
I hope this overview helps, let me know if I can provide further details.
Thanks Kevin