Consider using digest for `imageNames.imageBuilderName`

[dagood]

I received a question about this here: microsoft/go-infra-images#138 (review)

Specifically, would this reference:

docker-tools/eng/docker-tools/templates/variables/docker-images.yml

Line 2 in 47ba677

imageNames.imageBuilderName: mcr.microsoft.com/dotnet-buildtools/image-builder:2984976

be better as a digest reference, something like this?

imageNames.imageBuilderName: mcr.microsoft.com/dotnet-buildtools/image-builder@sha256:c67949a86f0816982bb7f58e637b43d3031c2aa338ecd3e98e6ba97f3222ed5e # 2984976

In normal cases, this won't change anything (because those are AzDO build IDs that I wouldn't expect to ever be rebuilt, and we accept new values without question anyway), but technically it could make very specific edge cases more traceable/reproducible.

Has this been considered?

---

I'm curious if this lines up with Docker ecosystem expectations nowadays--if digests are actually catching on for this kind of ref.

[lbussell]

Using image digests is more natural for this type of thing. There are two scenarios I see that benefit from using digests.

• Protecting against unexpected base image changes. Theoretically this shouldn't happen based on our infrastructure, but using digests would make it impossible. You can still have traceability using image labels/annotations. I think this is what you are referring to?
• Ensuring the ImageBuilder image hasn't been tampered with. Both switching to digests and Validate ImageBuilder container image signature before use in pipelines #2081 mitigate the impact in this scenario.

Both are good ideas for different reasons.

As an example from a related area, dotnet/runtime consumes buildtools-prereqs images via image digests now. They are updated via automation. https://github.com/dotnet/runtime/blob/main/eng/pipelines/common/templates/pipeline-with-resources.yml

[dagood]

Fully agree with those scenarios being the important ones.

You can still have traceability using image labels/annotations. I think this is what you are referring to?

I haven't seen these before. 😄 By traceability I just mean that given a build, it's easy to be sure what ImageBuilder it used, see the path that build took through dependency flow. Basically, the same as the scenarios you mentioned, but from the perspective of someone looking back at a problem and figuring out what actually happened or reproduce a bug.