buildx icon indicating copy to clipboard operation
buildx copied to clipboard

DOCKER_CONTENT_TRUST doesn't work with build using BuildKit

Open ericofusco opened this issue 2 years ago • 5 comments

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:

  1. Set environment variable
export DOCKER_CONTENT_TRUST=1
  1. Try to pull unsigned image just to confirm verification is working.
docker pull ericopf/java
  1. Create Dockerfile
FROM ericopf/java
ENV TEST 1
  1. Build image
docker build -t bad-image . 
  1. 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

ericofusco avatar Jul 28 '21 11:07 ericofusco

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?)

thaJeztah avatar Jul 28 '21 12:07 thaJeztah

@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.

thaJeztah avatar Jul 28 '21 12:07 thaJeztah

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> ....

crazy-max avatar Jul 28 '21 12:07 crazy-max

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 👍

thaJeztah avatar Mar 04 '22 15:03 thaJeztah

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

image

Padmavathi126 avatar Nov 21 '23 08:11 Padmavathi126