buildx

buildx copied to clipboard

Contributing guidelines

• [X] I've read the contributing guidelines and wholeheartedly agree

I've found a bug and checked that ...

• [X] ... the documentation does not mention anything about my problem
• [X] ... there are no open or closed issues that are related to my problem

Description

I'm trying to use the new SBOM attestation feature on docker buildx build and want to load that image into local docker image storage. This allows me to inspect the image, and also allows me to follow the recommendation in the documentation that I inspect the SBOM prior to pushing to a registry.

Expected behaviour

Based on the documentation that states

All BuildKit exporters support attestations

I expect the image to be built, pushed to the local image store, available for use, and for it to include the SBOM.

Actual behaviour

ERROR: docker exporter does not currently support exporting manifest lists

Buildx version

github.com/docker/buildx v0.10.4 c513d34

Docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.4
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.17.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  scan: Docker Scan (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-scan

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 23.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc version: v1.1.5-0-gf19387a
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.0-1031-aws
 Operating System: Ubuntu 22.04.2 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.785GiB
 Name: ip-10-159-26-159
 ID: d459883b-5b47-4f4f-9644-8caeba97bb59
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Builders list

NAME/NODE             DRIVER/ENDPOINT             STATUS  BUILDKIT PLATFORMS
buildkit-container *  docker-container
  buildkit-container0 unix:///var/run/docker.sock running v0.11.5  linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386
default               docker
  default             default                     running 23.0.2   linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386

Configuration

FROM containers.disney.com/ghost:5

Build logs

$ docker buildx build -o type=docker,name=foo --sbom=true .
[+] Building 0.0s (0/0)
ERROR: docker exporter does not currently support exporting manifest lists
root@ip-10-159-26-159:~# docker buildx version

Additional info

No response

I have the same issue with Docker 23.0.4/BuildKit 0.11.5 on Ubuntu 22.04. I tried several exporters but could not get any of them to work for me.

As a workaround, I build the image without attestation, run the tests, and then add attestation+"--push" to the docker build command. I'm not sure why the second build sometimes misses the cache, but when it hits the cache it's only the attestation+push that takes time in the second build.

I have the same issue with Docker 23.0.4/BuildKit 0.11.5 on Ubuntu 22.04. I tried several exporters but could not get any of them to work for me.

As a workaround, I build the image without attestation, run the tests, and then add attestation+"--push" to the docker build command. I'm not sure why the second build sometimes misses the cache, but when it hits the cache it's only the attestation+push that takes time in the second build.

What I toyed with was doing the build with attestation+push and then pulled down the sbom to save it as a CI job artifact. Fortunately, only the manifest/sbom gets pulled (and not the full image) so this turns out being pretty quick. It also avoids any potential cache misses on the rebuild.

The Verify SBOM attestations section in the docs have an example that works:

$ docker buildx build \
  --sbom=true \
  --output type=local,dest=out .

i.e. use the local exporter, not docker.

The same principle works when using buildx bake as well, using --set=<my-target>.output=type=local,dest=out.

The part of the docs you quote does seem to be incorrect:

All BuildKit exporters support attestations

in that the docker exporter doesn't support attestations. I think that's to be expected, because the docker exporter doesn't export OCI images, it uses the old docker-specific format that doesn't support modern features like multi-platform image manifests.

If you don't want to output the image locally (and if the image is not private) another option is to push it to the https://ttl.sh/ registry and then use docker buildx imagetools inspect <image> to look at the metadata. It's easier to look at the data from a local export though.

We can try to use the local exporter, but will then need to execute another build in order to push the image to a registry so it can actually be used.

A build --load would be most advantageous, as then we have the image locally, can fetch the SBOM, save it as a build artifact, and then can push the image to the desired registry/registries.