docker / docker/github-builder

Question on verification target

Đang mở
#153 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
83
Fork
23
Merge trung bình
2 ngày 22 giờ
Pull request đã merge (30 ngày)
8

Mô tả

Hi, and thanks a lot for this useful action 🙂 .

I was experimenting a bit with it and I have a question. From an end-user perspective, i.e., someone who is about to pull an image and use it locally, what's the recommended flow to verify it? I see there's an independent workflow for verifying images (docker/github-builder/.github/workflows/verify.yml@v1), but I'd like some help to understand what is it verifying, and how one can simulate it locally.

For example, I've built ghcr.io/apyrgio/dangerzone-test-github-builder@sha256:8eb497e92ed7071fc925e306214a6368bb2a3c90939ce15123d09471d3ba5a66 using this workflow.

Looking at the build job of this workflow, in the "Set result output" step, I see the following build output:

{
  "verifyCommands": "cosign verify --experimental-oci11 --new-bundle-format --certificate-oidc-issuer https://token.actions.githubusercontent.com/ --certificate-identity-regexp ^https://github.com/docker/github-builder/.github/workflows/build.yml.*$ ghcr.io/apyrgio/dangerzone-test-github-builder@sha256:c40cc89132c63ef82310cf1a2c05a6ad656ec88b9a9d29246825b470f1354a57",
  "imageDigest": "sha256:8eb497e92ed7071fc925e306214a6368bb2a3c90939ce15123d09471d3ba5a66",
  "artifactName": "",
  "signed": true
}

It seems that the verifyCommands field includes the commands that a user can run locally to verify the container image. What I'm not sure about is what we are verifying here.

In this case, the cosign verify command verifies the sha256:c40cc89132c63ef82310cf1a2c05a6ad656ec88b9a9d29246825b470f1354a57 manifest, which includes an in-toto attestation for the sha256:37ca0e50004ab4b4a51e6f87e6d9528a7d000e0a3702ff0a3c59181f7a558443 manifest, which is basically the image data for the linux/amd64 platform.

But the user will not pull this digest. They will instead pull either the root one, the platform specific one, or the image tag. For all the above, if they to run cosign verify ... against them, they will get the following:

Error: no signatures found
error during command execution: no signatures found

Should there be signatures for these digests?

Finally, the provided cosign verify ... command ensures that the image was created by this GitHub action. What's much more interesting though is the other attestation attributes, such as the repository or the source commit hash. If a user wants to verify against those, should they use the cosign verify ... command, or switch to cosign verify-attestation ... and pass a CUE policy or similar?

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu với docker/github-builder/.github/workflows/verify.yml@v1 và bước “Set result output” của build job trong .github/workflows/github-build.yml. Theo dõi các verifyCommands được phát ra cùng với các digest của image, platform và attestation, sau đó ghi lại quy trình xác minh cục bộ được khuyến nghị và cách người dùng nên xác minh các thuộc tính của repository hoặc source-commit. Được xem là hoàn tất khi hành vi của digest và lựa chọn giữa các lệnh xác minh cosign được giải thích rõ ràng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
docker, github-actions
Lĩnh vực
devops, security
Loại issue
Tài liệu
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
38/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.