docker / docker/github-builder
Question on verification target
还没有人认领这个 Issue。
- 主要语言
- 没有语言数据
- 星标
- 83
- 派生
- 23
- 平均合并
- 2 天 22 小时
- 30 天内合并 PR
- 8
描述
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?
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 docker/github-builder/.github/workflows/verify.yml@v1 以及 .github/workflows/github-build.yml 中 build job 的“Set result output”步骤开始。跟踪发出的 verifyCommands 以及 image、platform 和 attestation digest,然后记录推荐的本地验证流程,以及用户应如何验证 repository 或 source-commit 属性。只有在明确解释 digest 行为以及如何在 cosign 验证命令之间进行选择后,才算完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- docker, github-actions
- 领域
- devops, security
- Issue 类型
- 文档
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 38/100