Attestations from buildx

[jedevc]

Adds an --attest flag to the build command, to add SBOM and provenance attestations. Example usage:

# basic invocation
$ docker buildx build . -t foo --attest type=sbom --attest type=provenance

# invocation with parameters
$ docker buildx build . -t foo --attest type=sbom,generator="<registry>/<image>" --attest type=provenance,mode="<mode>"

Also adds an attest field to bake. Example usage:

target "myimage" {
  attest = [
    "type=sbom"
  ]
}

The attestation parameters are forwarded to buildkit, which should then include them in the build.

[tonistiigi]

Could we consider some less verbose alternatives? The issue I have with current is that I don't think the common case is easy enough (with type= etc).

The other is with the provenance. We want to enable the "min mode"(one without the arguments and build steps) of provenance by default like the previous buildinfo implementation was. This would mean that users have two options: they can change it to max mode or they can disable it. With current syntax --attest type=provenance,mode=disabled, --attest type=provenance,mode=max.

An alternative would be --sbom --provenance , I guess the arguments would need to be [bool=true|csv]. Not sure how many more attestation types we will need in the future.

Or maybe allow type= to be optional in first csv value: --attest sbom --attest sbom,generator=foo ?

Any ideas? @crazy-max @AkihiroSuda @cpuguy83 @sudo-bmitch

[sudo-bmitch]

This may be mixing two things that would be useful to keep separate. Build attestations, like in-toto, and the SBOM.

The build attestations may be built directly into buildkit. Much of the data is already in the image config json, just in the wrong format, with the layers and history.

For the SBOM, having that as "batteries included but swappable" feels like the best pattern. For the "included" version, a simple bool flag would be nice. For "swappable", I'm inclined to make one of those options to specify a target stage that creates the SBOM, and an optional filename. That way I can run one or more SBOM generators as a stage, e.g. one for the Go modules, and another for the alpine packages. The complexity will quickly grow with multiple SBOM formats, xml vs json, and SPDX vs cyclonedx. In OCI we're leaning towards each format being a separate artifact that can be separately pulled.

I'm not sure how much that helps with this specific PR, but the result of it points to a flag that allows the SBOM part to get rather complex.

[crazy-max]

I think the current format is fine and aligned with flags we currently have like --output but we could have some shorthands like --push for --output=type=registry.

So --sbom would be a shorthand for --attest=type=sbom,generator=<default_buildkit_scanner_image>. generator key optional so --sbom <registry>/<image> would be --attest=type=sbom,generator=<registry>/<image>.

[cpuguy83]

Agree with @crazy-max here --sbom and --provenance would make good short-hands for probably very common needs.
Even potentially some extra positional type like --sbom=[generator][, k/v opts] where [generator] is optional but must be first if provided and can be followed by k/v opts like mode=max.

Environment variables to set these would also be extremely useful, to me.

[jedevc]

I've prototyped an --sbom and --provenance flag, taking either booleans (to directly enable or disable), or a CSV that the long form would be of --attest type=<sbom/provenance>,[args].

I think it would be a good idea to leave ourselves free to add more SBOM options in the future, so I think we probably want to explicitly have --sbom generator=<image> instead of something of the form --sbom <image>, which might make it more complicated to add more options in the future?

[crazy-max]

I think we probably want to explicitly have --sbom generator=<image> instead of something of the form --sbom <image>, which might make it more complicated to add more options in the future?

SGTM

CI does not look happy, need to regen docs: make docs

[crazy-max]

For bake, maybe we should also have the same shorthands like --set=*.output=type=registry for --push.

[tonistiigi]

Now that moby/buildkit#3342 is merged could you update this to inline-only by default?

[jedevc]

Have updated with inline-only - it's a little fiddly, because we want support in bake. Essentially, if we want --sbom and --attest flags at the bake level that translate into a --set, we need an explicit way to disable an attestation from inside a target field. There may be a simpler way to do it that I'm not seeing though.

If it's too messy with the enabled field, we could just remove support for the --sbom/--provenance flags to bake which would let the code be a lot neater.

[jedevc]

Quick note to avoid confusion: we need opt.Attests to have some way of signalling a value that was explicitly disabled - we do that with nil.

This needs to be done here, so that we can ensure to only check the caps if we want something other than the default - otherwise, we want the mode=min,inline-only=true provenance to be attached on a best-effort basis, since the user hasn't explicitly opted in.

[codysnider]

I feel it worth mentioning that this changes breaks every multi-architecture build until the --sbom=false and --provenance=false CLI flags are added to the docker buildx build command.

To preserve compatibility for those who rely on buildx for multi-architecture builds, these features should be disabled by default and only add attestations when explicitly set. At the very least, there should be a grace period in which the cli interface alerts the developer to a behavior change.

[crazy-max]

this changes breaks every multi-architecture build

If you have a repro please open an issue. Thanks.