证明构建来源
v1.4.4
actions/attest-build-provenance为工作流程工件生成签名的构建来源证明。由 @actions/attest 包内部驱动。
证明使用 in-toto 格式将某些主题（命名工件及其摘要）绑定到 SLSA 构建来源谓词。
使用短期 Sigstore 颁发的签名证书为证明生成可验证的签名。如果启动 GitHub Actions 工作流程的存储库是公共的，则 Sigstore 的公共物品实例将用于生成证明签名。如果存储库是私有/内部的，它将使用 GitHub 私有 Sigstore 实例。
创建并签署证明后，它将上传到 GH 证明 API 并与启动工作流的存储库关联。
可以使用 GitHub CLI 中的attestation命令来验证证明。
有关工件证明的更多信息，请参阅使用工件证明来确定构建的来源。
在 GitHub Actions 工作流程中，该工作流程构建了一些您想要证明的工件：
确保设置以下权限：
permissions :
id-token : write
attestations : write id-token权限使操作能够创建请求 Sigstore 签名证书所需的 OIDC 令牌。 attestations权限对于持久证明是必需的。
构建工件后，将以下内容添加到您的工作流程中：
- uses : actions/attest-build-provenance@v1
with :
subject-path : ' ' subject-path参数应标识您要为其生成证明的工件。
参见action.yml
- uses : actions/attest-build-provenance@v1
with :
# Path to the artifact serving as the subject of the attestation. Must
# specify exactly one of "subject-path" or "subject-digest". May contain a
# glob pattern or list of paths (total subject count cannot exceed 2500).
subject-path :
# SHA256 digest of the subject for the attestation. Must be in the form
# "sha256:hex_digest" (e.g. "sha256:abc123..."). Must specify exactly one
# of "subject-path" or "subject-digest".
subject-digest :
# Subject name as it should appear in the attestation. Required unless
# "subject-path" is specified, in which case it will be inferred from the
# path.
subject-name :
# Whether to push the attestation to the image registry. Requires that the
# "subject-name" parameter specify the fully-qualified image name and that
# the "subject-digest" parameter be specified. Defaults to false.
push-to-registry :
# Whether to attach a list of generated attestations to the workflow run
# summary page. Defaults to true.
show-summary :
# The GitHub token used to make authenticated API requests. Default is
# ${{ github.token }}
github-token :| 姓名 | 描述 | 例子 |
|---|---|---|
bundle-path | 包含生成的证明的文件的绝对路径 | /tmp/attestation.jsonl |
证明以 JSON 序列化的 Sigstore 捆绑包格式保存。
如果同时证明多个主题，则每个证明将在单独的行上写入输出文件（使用 JSON 行格式）。
同时认证的科目不得超过2500个。主题将按 50 个批次进行处理。在最初的 50 个批次之后，每个后续批次将产生指数级增加的延迟（每批次延迟上限为 1 分钟），以避免压垮证明 API。
对于基本用例，只需将attest-build-provenance操作添加到您的工作流程中，并提供您要为其生成证明的工件的路径。
name : build-attest
on :
workflow_dispatch :
jobs :
build :
permissions :
id-token : write
contents : read
attestations : write
steps :
- name : Checkout
uses : actions/checkout@v4
- name : Build artifact
run : make my-app
- name : Attest
uses : actions/attest-build-provenance@v1
with :
subject-path : ' ${{ github.workspace }}/my-app '如果您要生成多个工件，则可以通过在subject-path输入中使用通配符为每个工件生成出处证明。
- uses : actions/attest-build-provenance@v1
with :
subject-path : ' dist/**/my-bin-* '有关受支持的通配符以及行为和文档，请参阅@actions/glob，它在内部用于搜索文件。
或者，您可以使用逗号或换行符分隔列表显式列出多个主题：
- uses : actions/attest-build-provenance@v1
with :
subject-path : ' dist/foo, dist/bar ' - uses : actions/attest-build-provenance@v1
with :
subject-path : |
dist/foo
dist/bar使用容器映像时，您可以使用subject-name和subject-digest输入调用操作。
如果您想使用push-to-registry选项将证明发布到容器注册表，则subject-name指定完全限定的映像名称（例如“ghcr.io/user/app”或“acme. azurecr.io/user/app”）。不要将标签作为图像名称的一部分 - 所证明的特定图像由提供的摘要标识。
证明捆绑包根据 Cosign Bundle 规范存储在 OCI 注册表中。
注意：推送到 Docker Hub 时，请使用“index.docker.io”作为镜像名称的注册表部分。
name : build-attested-image
on :
push :
branches : [main]
jobs :
build :
runs-on : ubuntu-latest
permissions :
id-token : write
packages : write
contents : read
attestations : write
env :
REGISTRY : ghcr.io
IMAGE_NAME : ${{ github.repository }}
steps :
- name : Checkout
uses : actions/checkout@v4
- name : Login to GitHub Container Registry
uses : docker/login-action@v3
with :
registry : ${{ env.REGISTRY }}
username : ${{ github.actor }}
password : ${{ secrets.GITHUB_TOKEN }}
- name : Build and push image
id : push
uses : docker/[email protected]
with :
context : .
push : true
tags : ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
- name : Attest
uses : actions/attest-build-provenance@v1
id : attest
with :
subject-name : ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
subject-digest : ${{ steps.push.outputs.digest }}
push-to-registry : true
