Alauda Container Platform Pipelines Docs
  • 简体中文

    • 构建系统来源验证

    在 SLSA provenance 中，有一个 builder.id 字段，用于指示镜像的构建环境。

    在本文档中，我们将使用此 builder.id 字段验证镜像。

    TIP

    由于 Tekton Chains 已在准备阶段完成镜像签名和 SLSA provenance 生成，我们可以直接复用 快速入门：签名来源 中的流程和镜像。

    本文档将重点介绍如何验证 SLSA provenance。

    目录

    功能概述使用场景前提条件流程概述分步说明步骤 1-7：（可选）基本设置步骤 8：（可选）使用 cosign 验证构建器信息方式 1：使用 CUE 进行验证方式 2：使用 Rego 进行验证步骤 9：使用 Kyverno 验证签名步骤 9.1：创建 Kyverno 策略，仅允许部署在指定构建环境中构建的镜像步骤 9.2：验证策略步骤 10：清理资源预期结果参考

    功能概述

    此方法使用 Chains 自动为构建的镜像生成 SLSA Provenance，然后使用 Kyverno 验证该 provenance：

    1. 配置 Tekton Chains，自动为构建的镜像生成 SLSA Provenance。
    2. 使用 buildah Tekton Task 构建镜像。
    3. （可选）使用 cosign CLI 验证证明。
    4. 配置 Kyverno 规则以验证证明。
    5. 使用该镜像创建 Pod，以验证证明。

    使用场景

    以下场景需要参考本文档中的指导：

    • 使用 SLSA provenance 验证容器镜像的构建环境
    • 使用 CUE 或 Rego 策略实现构建系统来源验证
    • 强制执行安全策略，仅允许部署在特定构建环境中构建的镜像
    • 在 CI/CD 流水线中设置自动化构建系统来源验证
    • 确保生产环境中构建系统来源的完整性和真实性

    前提条件

    • 已安装 Tekton Pipelines、Tekton Chains 和 Kyverno 的 Kubernetes 集群
    • 已启用镜像推送功能的 registry
    • 已安装并配置 kubectl CLI，可访问您的集群
    • 已安装 cosign CLI 工具
    • 已安装 jq CLI 工具

    流程概述

    步骤操作描述
    1生成签名密钥使用 cosign 创建用于签名制品的密钥对
    2设置身份验证配置用于推送镜像的 registry 凭证
    3配置 Tekton Chains设置 Chains 使用 OCI 存储并配置签名
    4创建示例流水线创建包含所需任务和工作区的流水线定义
    5运行示例流水线使用正确的配置创建并运行 PipelineRun
    6等待签名等待 Chains 为 PipelineRun 签名
    7获取镜像信息从 PipelineRun 中提取镜像 URI 和摘要
    8（可选）使用 cosign 验证签名使用 cosign CLI 验证镜像证明
    9使用 Kyverno 验证签名使用 Kyverno 策略配置并验证镜像证明
    10清理资源删除测试 Pod 和策略

    分步说明

    步骤 1-7：（可选）基本设置

    NOTE

    如果更改 builder.id 字段，则需要重新运行流水线以生成镜像。 因为旧镜像未使用新的 builder.id 进行签名，所以会被策略阻止。

    否则，可以跳过此步骤，使用旧镜像验证策略。

    这些步骤与快速入门：签名的来源证明指南完全相同。请按照该指南中的说明完成以下操作：

    步骤 8：（可选）使用 cosign 验证构建器信息

    TIP

    此步骤为可选步骤，在需要使用 cosign 验证镜像构建器的真实性时执行。

    如果您对如何使用 CUE 或 Rego 验证构建器信息感兴趣，可以继续阅读以下内容。

    根据获取签名公钥部分获取签名公钥。

    Cosign 提供了两种验证证明的方式：

    下面将介绍这两种方式的验证方法。

    方式 1：使用 CUE 进行验证

    生成用于验证构建器信息的 CUE 文件。

    // The predicate must match the following constraints.
predicate: {
    builder: {
        id: "https://alauda.io/builders/tekton/v1"
    }
}

    将 CUE 文件保存到 builder.cue

    使用 cosign 验证构建器信息。

    # Disable tlog upload and enable private infrastructure
$ export COSIGN_TLOG_UPLOAD=false
$ export COSIGN_PRIVATE_INFRASTRUCTURE=true

$ export IMAGE=<<registry>/test/chains/demo-1:latest@sha256:93635f39cb31de5c6988cdf1f10435c41b3fb85570c930d51d41bbadc1a90046>

$ cosign verify-attestation --key cosign.pub --type slsaprovenance --policy builder.cue $IMAGE

    如果收到如下输出，则表示构建器信息验证成功。

    will be validating against CUE policies: [builder.cue]
will be validating against CUE policies: [builder.cue]

Verification for <registry>/test/chains/demo-1:latest@sha256:8ac1af8dd89652bf32abbbd0c5f667ae9fe6d92c91972617e70b5398303c8e27 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{"payloadType":"application/vnd.in-toto+json","payload":"","signatures":[]}

    将 builder.cue 文件中的构建器 ID 更改为其他值 https://alauda.io/builders/tekton/v2，然后再次进行验证。

    $ cosign verify-attestation --key cosign.pub --type slsaprovenance --policy builder.cue $IMAGE

    如果收到如下输出，则表示构建器信息验证失败。

    will be validating against CUE policies: [builder.cue]
will be validating against CUE policies: [builder.cue]
There are 2 number of errors occurred during the validation:

- predicate.builder.id: conflicting values "https://alauda.io/builders/tekton/v1" and "https://alauda.io/builders/tekton/v2"
- predicate.builder.id: conflicting values "https://alauda.io/builders/tekton/v1" and "https://alauda.io/builders/tekton/v2"
Error: 2 validation errors occurred
error during command execution: 2 validation errors occurred

    方式 2：使用 Rego 进行验证

    生成用于验证构建器信息的 Rego 文件。

    package signature

default allow = false

# Define the allowed builder.id
allowed_builder_id = "https://alauda.io/builders/tekton/v1"

# Verify the builder.id
allow {
    # Check if the builder.id in the predicate is equal to the allowed value
    input.predicate.builder.id == allowed_builder_id
}

# Return error message when not match
deny[msg] {
    input.predicate.builder.id != allowed_builder_id
    msg := sprintf("unexpected builder.id: %v, expected: %v", [input.predicate.builder.id, allowed_builder_id])
}

    将 Rego 文件保存到 builder.rego

    使用 cosign 验证构建器信息。

    # Disable tlog upload and enable private infrastructure
$ export COSIGN_TLOG_UPLOAD=false
$ export COSIGN_PRIVATE_INFRASTRUCTURE=true

$ export IMAGE=<<registry>/test/chains/demo-1:latest@sha256:93635f39cb31de5c6988cdf1f10435c41b3fb85570c930d51d41bbadc1a90046>

$ cosign verify-attestation --key cosign.pub --type slsaprovenance --policy builder.rego $IMAGE

    如果收到如下输出，则表示构建器信息验证成功。

    will be validating against Rego policies: [builder.rego]
will be validating against Rego policies: [builder.rego]

Verification for <registry>/test/chains/demo-1:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{"payloadType":"application/vnd.in-toto+json","payload":"","signatures":[]}

    将 builder.rego 文件中的构建器 ID 更改为其他值 https://alauda.io/builders/tekton/v2，然后再次进行验证。

    $ cosign verify-attestation --key cosign.pub --type slsaprovenance --policy builder.rego $IMAGE

    如果收到如下输出，则表示构建器信息验证失败。

    will be validating against Rego policies: [builder.rego]
will be validating against Rego policies: [builder.rego]
There are 2 number of errors occurred during the validation:

- expression value, false, is not true
- expression value, false, is not true
Error: 2 validation errors occurred
error during command execution: 2 validation errors occurred

    步骤 9：使用 Kyverno 验证签名

    TIP

    此步骤需要集群管理员权限。

    来源证明的内容大致如下，我们将使用 builder.id 字段验证构建环境。

    {
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "predicate": {
    "buildType": "tekton.dev/v1beta1/TaskRun",
    "builder": {
      "id": "https://alauda.io/builders/tekton/v1"
    },
    "materials": [
      {
        "digest": {
          "sha256": "8d5ea9ecd9b531e798fecd87ca3b64ee1c95e4f2621d09e893c58ed593bfd4c4"
        },
        "uri": "oci://<registry>/devops/tektoncd/hub/buildah"
      }
    ],
    "metadata": {
      "buildFinishedOn": "2025-06-06T10:21:27Z",
      "buildStartedOn": "2025-06-06T10:20:55Z"
    }
  }
}

    步骤 9.1：创建 Kyverno 策略，仅允许部署在指定构建环境中构建的镜像

    TIP

    有关 Kyverno ClusterPolicy 的更多详细信息，请参阅 Kyverno ClusterPolicy

    策略如下：

    apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-tekton-built-images
spec:
  webhookConfiguration:
    failurePolicy: Fail
    timeoutSeconds: 30
  background: false
  rules:
    - name: check-image
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - policy
      verifyImages:
        - imageReferences:
            - "*"
            # - "<registry>/test/*"
          skipImageReferences:
            - "ghcr.io/trusted/*"
          failureAction: Enforce
          verifyDigest: false
          required: false
          useCache: false
          imageRegistryCredentials:
            allowInsecureRegistry: true
            secrets:
              # The credential needs to exist in the namespace where kyverno is deployed
              - registry-credentials

          attestations:
            - type: https://slsa.dev/provenance/v0.2
              attestors:
                - entries:
                    - keys:
                        publicKeys: |- # <- The public key of the signer
                          -----BEGIN PUBLIC KEY-----
                          MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFZNGfYwn7+b4uSdEYLKjxWi3xtP3
                          UkR8hQvGrG25r0Ikoq0hI3/tr0m7ecvfM75TKh5jGAlLKSZUJpmCGaTToQ==
                          -----END PUBLIC KEY-----

                        ctlog:
                          ignoreSCT: true

                        rekor:
                          ignoreTlog: true
              conditions:
                - all:
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://alauda.io/builders/tekton/v1"
                      message: "The builder.id must be equal to https://alauda.io/builders/tekton/v1, not {{ builder.id }}"
    Explanation of YAML fields
    • 该策略与镜像签名验证中的策略基本一致。下面仅介绍其中的差异。
    • spec.rules[0].verifyImages[].attestations[0].conditions
      • type：SLSA 来源证明类型为 https://slsa.dev/provenance/v0.2 或 https://slsa.dev/provenance/v1。
      • attestors：与上述相同。
      • conditions：要验证的条件。
        • all：必须满足所有条件。
          • key: "{{ builder.id }}"：检查证明中的 builder.id 字段是否等于 https://alauda.io/builders/tekton/v1

    需要调整的配置

    • spec.rules[].attestors[].entries[].keys.publicKeys：签名者的公钥。
      • 此公钥与 signing-secrets secret 中的公钥 cosign.pub 相同。
      • 可以从获取签名公钥部分获取公钥。

    将策略保存到名为 kyverno.verify-tekton-built-images.yaml 的 yaml 文件中，并使用以下命令应用：

    $ kubectl apply -f kyverno.verify-tekton-built-images.yaml

clusterpolicy.kyverno.io/verify-tekton-built-images configured

    步骤 9.2：验证策略

    在定义策略的 policy 命名空间中创建 Pod，以验证策略。

    使用构建的镜像创建 Pod。

    $ export NAMESPACE=<policy>
$ export IMAGE=<<registry>/test/chains/demo-1:latest@sha256:93635f39cb31de5c6988cdf1f10435c41b3fb85570c930d51d41bbadc1a90046>

$ kubectl run -n $NAMESPACE built --image=${IMAGE} -- sleep 3600

pod/built created

    Pod 将成功创建。

    $ kubectl get pod -n $NAMESPACE built

NAME      READY   STATUS    RESTARTS   AGE
built   1/1     Running   0          10s

    将 ClusterPolicy 中的构建器 ID 更改为其他值 https://alauda.io/builders/tekton/v2，然后再次进行验证。

    conditions:
  - all:
      - key: "{{ builder.id }}"
        operator: Equals
        value: "https://alauda.io/builders/tekton/v2"
        message: "The builder.id must be equal to https://alauda.io/builders/tekton/v2, not {{ builder.id }}"
    $ kubectl run -n $NAMESPACE unbuilt --image=${IMAGE} -- sleep 3600

    如果收到如下输出，则表示 Pod 已被策略阻止。

    Error from server: admission webhook "mutate.kyverno.svc-fail" denied the request:

resource Pod/policy/unbuilt was blocked due to the following policies

verify-tekton-built-images:
  check-image: 'image attestations verification failed, verifiedCount: 0, requiredCount:
    1, error: .attestations[0].attestors[0].entries[0].keys: attestation checks failed
    for <registry>/test/chains/demo-1@sha256:93635f39cb31de5c6988cdf1f10435c41b3fb85570c930d51d41bbadc1a90046
    and predicate https://slsa.dev/provenance/v0.2: The builder.id must be equal to
    https://alauda.io/builders/tekton/v2, not https://alauda.io/builders/tekton/v1'

    步骤 10：清理资源

    删除前面步骤中创建的 Pod。

    $ export NAMESPACE=<policy>
$ kubectl delete pod -n $NAMESPACE built

    删除策略。

    $ kubectl delete clusterpolicy verify-tekton-built-images

    预期结果

    完成本指南后：

    • 您将拥有一个可正常运行的 Tekton Chains 设置，用于生成 SLSA provenance
    • 您的容器镜像将在构建过程中自动使用 build system provenance 进行签名
    • 您可以使用 CUE 或 Rego 策略验证镜像的构建环境
    • 只有在指定构建环境中构建的镜像才能部署到指定命名空间
    • 在未经授权的构建环境中构建的镜像将被 Kyverno 策略自动阻止
    • 您已为容器镜像实施基本的 build system provenance verification 控制

    本指南为在 CI/CD 流水线中实施 build system provenance verification 奠定了基础。在生产环境中，您应：

    1. 配置适当的命名空间隔离和访问控制
    2. 为签名密钥实施安全的密钥管理
    3. 设置策略违规的监控和告警
    4. 定期轮换签名密钥并更新安全策略
    5. 考虑实施其他安全控制，例如漏洞扫描

    参考