Initial attestations support

[jedevc]

This PR introduces support for in-toto attestations, as specified in part 1 of https://github.com/moby/buildkit/issues/2773#issuecomment-1146479848.

This is dependent on https://github.com/moby/buildkit/pull/2929, and includes a commit from there to better handle garbage collection of attestation refs.

In it's current state, this is a first-pass - and some things are expected to change before merge:

• Media types for exported content
  • Additionally, these need to be added to the image pusher code to prevent encountered unknown type ... children may not be fetched messages.
• OS/Platform values for attestations - currently selected none/none
• Exact Gateway API protobuf format
• Attestation struct format
• Hopefully a few more tests

[jedevc]

Not quite sure how this model would interact with tooling that generates a lot of attestations. One possible way might be to allow grouping attestations together into layers, though I'm not quite sure the mechanics of the API that would use.

[jedevc]

Another complexity that's come up that we might want to investigate - we might want to have the capacity to have scanners able to analyze individual layers - so for that we might want to expose the ability to create attestations about single layers. Exactly how a scanner might create these attestations feels like something that's up to each scanner, and the interface that gets defined for that, but the storage format is something to maybe work out sooner. We could potentially allow attaching attestations to arbitrary Refs and then translate them to layer digests as part of the exporter?

[errordeveloper]

Another complexity that's come up that we might want to investigate - we might want to have the capacity to have scanners able to analyze individual layers - so for that we might want to expose the ability to create attestations about single layers. Exactly how a scanner might create these attestations feels like something that's up to each scanner, and the interface that gets defined for that, but the storage format is something to maybe work out sooner. We could potentially allow attaching attestations to arbitrary Refs and then translate them to layer digests as part of the exporter?

One use-case would be to produce attestations about what buildkit itself does, i.e. for a RUN statement you would want to have a trace of what binaries were exec'ed, what files openend etc. You would probably want to included checksum of each file as well as stdout and stderr. For COPY/ADD you do want file chechsums too as well as list of any files that had been overwritten. These use-cases would probably translate to buildkit features, perhaps these could helpeful in shaping some aspects of the implementation.

[jedevc]

Based on discussions, a couple notes:

• Buildkit will have to have some knowledge of attestations somewhere - we can't entirely treat them like a completely opaque blob. It might still be worth distinguishing between the concept of a "generic buildkit attestation" which is then translated to an in-toto attestation at export, like the current code does?
• Layer-based attestations are probably not going to be a thing, since they may not be particularly useful, since they don't necessarily map explicitly to the frontend's input (like a dockerfile). How files in an image map to an instruction, or the layer-based structure of an image is expressed in SBOMs is likely an issue to be solved at the frontend level, and expressed within the structure of the attestation if necessary.
• Attestation bundling is already sort of supported atm, by splitting out each platform's attestations into a separate manifest. In the future, we could allow splitting out attestations further into multiple attestation manifests per platform if necessary if we want to split out bundles even more - but we can likely address this later as we see how the unbundled stuff scales.

[jedevc]

I'm happy with the state of this now :smile: A couple of follow-ups will likely be necessary: adding support for other exporters (e.g. tar/local), clean-up of conversions between different Result types (which makes the attestation plumbing ugly), and probably other things as we add SBOMs.

[jedevc]

As discussed with @tonistiigi, to keep the scope of this PR low, a list of the planned follow-ups:

• [x] Suppress warning messages from containerd pusher
  • https://github.com/moby/buildkit/pull/3063
• [ ] Export attestations with local/tar exporters
  • https://github.com/moby/buildkit/issues/3184
• [x] Tidy up the Result types (so we need less messy conversion code)
  • https://github.com/moby/buildkit/pull/3036
  • https://github.com/moby/buildkit/pull/3038
• [x] Set oci-mediatypes when using attestations and annotations, instead of producing not-completely-in-spec manifests and manifest lists
  • https://github.com/moby/buildkit/pull/3061