buildx
buildx copied to clipboard
DOCKER_CONTENT_TRUST doesn't work with build using BuildKit
Description
It seems docker build is ignoring DOCKER_CONTENT_TRUST when building an image that references one that's not signed.
Steps to reproduce the issue:
- Set environment variable
export DOCKER_CONTENT_TRUST=1
- Try to pull unsigned image just to confirm verification is working.
docker pull ericopf/java
- Create
Dockerfile
FROM ericopf/java
ENV TEST 1
- Build image
docker build -t bad-image .
- Confirm image is built
docker image ls bad-iamge
Describe the results you received:
Docker pull fails as expected with the message below:
Error: remote trust data does not exist for docker.io/ericopf/java: notary.docker.io does not have trust data for docker.io/ericopf/java
docker build
works fine and image is successfully built from an image that's not signed.
Describe the results you expected:
Failure during docker build
showing the same error from docker pull
.
Output of docker version
:
Client:
Cloud integration: 1.0.17
Version: 20.10.7
API version: 1.41
Go version: go1.16.4
Git commit: f0df350
Built: Wed Jun 2 11:56:22 2021
OS/Arch: darwin/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.7
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: b0f5bc3
Built: Wed Jun 2 11:54:58 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.6
GitCommit: d71fcd7d8303cbf684402823e425e9dd2e99285d
runc:
Version: 1.0.0-rc95
GitCommit: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Output of docker info
:
docker info
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
compose: Docker Compose (Docker Inc., v2.0.0-beta.6)
scan: Docker Scan (Docker Inc., v0.8.0)
Server:
Containers: 15
Running: 1
Paused: 0
Stopped: 14
Images: 7
Server Version: 20.10.7
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
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 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d71fcd7d8303cbf684402823e425e9dd2e99285d
runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 5.10.25-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.941GiB
Name: docker-desktop
ID: EAVA:MGOX:C5VK:TQJU:CYJV:LXOU:5WPD:YGEK:XQD6:IVHM:OMSN:NUYK
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 41
Goroutines: 46
System Time: 2021-07-28T11:02:23.326054793Z
EventsListeners: 4
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional environment details (AWS, VirtualBox, physical, etc.):
DOCKER_CONTENT_TRUST=1
Thanks for reporting and the clear reproduction steps; looks like this is related to BuildKit (which may not (yet) support this).
Building with BuildKit enabled "succeeds";
DOCKER_CONTENT_TRUST=1 DOCKER_BUILDKIT=1 docker build -t bad-image -<<EOF
FROM ericopf/java
ENV TEST 1
EOF
[+] Building 26.6s (6/6) FINISHED
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 71B 0.0s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/ericopf/java:latest 1.8s
=> [auth] ericopf/java:pull token for registry-1.docker.io 0.0s
=> [1/1] FROM docker.io/ericopf/java@sha256:68d8b689858f2ab510b725b5db482f1313edc1ad87b0a315a0075c5c05ddddf2 24.6s
=> => resolve docker.io/ericopf/java@sha256:68d8b689858f2ab510b725b5db482f1313edc1ad87b0a315a0075c5c05ddddf2 0.0s
=> => sha256:68d8b689858f2ab510b725b5db482f1313edc1ad87b0a315a0075c5c05ddddf2 1.37kB / 1.37kB 0.0s
=> => sha256:b42c9dc8da6f8711e5c9500bb15bf38feb3485f643827b35e446aa2c3116bd74 1.13kB / 1.13kB 0.0s
=> => sha256:513fe3029c08c44d4284433bbaadf9532d00f1fccd984200166b1ddccbc7a944 657.57kB / 657.57kB 0.9s
=> => sha256:7d9e79e19cb9d9c42fa8c4355a2ea4135576ed66ae6adb85bcbee39c0d837edc 8.09MB / 8.09MB 17.8s
=> => sha256:70ae9b2cb6366cb5381b6c8a3ee32468cb33d19b4be867b02ddd609dbd9f5163 694.11kB / 694.11kB 3.3s
=> => extracting sha256:513fe3029c08c44d4284433bbaadf9532d00f1fccd984200166b1ddccbc7a944 0.4s
=> => sha256:a8effa8f622c3ab5e172ee1587b55e56b046b270917ecef350403a840301da90 657.95kB / 657.95kB 2.6s
=> => sha256:37cbddbbcdadd7cf5eaf62dc1df5c1d102a2e4dca23be1c91042446a05c5a013 21.28MB / 21.28MB 22.9s
=> => extracting sha256:7d9e79e19cb9d9c42fa8c4355a2ea4135576ed66ae6adb85bcbee39c0d837edc 0.4s
=> => extracting sha256:70ae9b2cb6366cb5381b6c8a3ee32468cb33d19b4be867b02ddd609dbd9f5163 0.1s
=> => extracting sha256:a8effa8f622c3ab5e172ee1587b55e56b046b270917ecef350403a840301da90 0.1s
=> => extracting sha256:37cbddbbcdadd7cf5eaf62dc1df5c1d102a2e4dca23be1c91042446a05c5a013 1.3s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:e30a741ec294a25fae7077eae63d02f1ff5247d7a8335e245aa704c82bb343f6 0.0s
=> => naming to docker.io/library/bad-image
Disabling BuildKit (DOCKER_BUILDKIT=0
) to use the classic builder, causes the build to fail:
DOCKER_CONTENT_TRUST=1 DOCKER_BUILDKIT=0 docker build -t bad-image -<<EOF
FROM ericopf/java
ENV TEST 1
EOF
Sending build context to Docker daemon
error during connect: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.41/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=bad-image&target=&ulimits=null&version=1": Error: remote trust data does not exist for docker.io/ericopf/java: notary.docker.io does not have trust data for docker.io/ericopf/java
I know there's https://github.com/docker/cli/issues/933 (which may be related / a reason for this?)
@tonistiigi @justincormack @crazy-max PTAL
I think we should at least clearly document this, and probably produce a warning if DOCKER_CONTENT_TRUST=1
is set.
Yes we should at least warn about that here.
If we want to handle trust reference on BuildKit we need to parse repo info with img ref and auth and also manage notary client. Wonder if it should be only part of Dockerfile frontend while retrieving image metadata (so only FROM
instructions) or if it should be done on LLB side to be able to handle RUN --mount=from=<image> ...
.
The BuildKit client code has been moved out of the CLI (and is now handled by Buildx); let me transfer this ticket to the buildx issue tracker 👍
The BuildKit client code has been moved out of the CLI (and is now handled by Buildx); let me transfer this ticket to the buildx issue tracker 👍
The BuildKit client code has been moved out of the CLI (and is now handled by Buildx); let me transfer this ticket to the buildx issue tracker 👍
Hi, it appears that the problem is still unresolved. When using DOCKER_CONTENT_TRUST=1 and DOCKER_BUILDKIT=0, Content Trust is functioning, but we're encountering a 'DEPRECATED' warning. Going forward, the use of the legacy builder is not recommended. How can I ensure the seamless integration of Docker Content Trust in my GitHub workflow without encountering any issues in the future