简体中文

了解 Tekton Chains

Tekton Chains 是 Tekton 生态系统中一个强大的安全组件，通过为使用 Tekton Pipelines 构建的工件生成、签名和存储溯源信息，帮助保护您的软件供应链安全。本文档深入解释了 Tekton Chains 的工作原理及其关键组件。

术语表

术语	描述
SLSA	软件工件供应链级别（Supply-chain Levels for Software Artifacts）——用于软件供应链完整性的安全框架
Signature	用于验证溯源数据真实性和完整性的加密证明
Attestation	关于软件工件的经过认证的元数据，遵循 in-toto 认证格式
Verification	检查认证数据真实性和完整性的过程
Type Hinting	特殊命名的结果/参数，帮助 Tekton Chains 理解输入和输出
Storage Backend	Tekton Chains 用于存储溯源和签名的系统

认证（Attestation）有多种谓词类型。

谓词类型	描述
SLSA Provenance	描述工件如何生成的元数据，包括构建过程、输入和环境
SBOM	列出软件产品所有组件及其关系的文档
Vulnerability Scan Results	列出软件产品中发现的所有漏洞的报告
Custom Metadata	关于软件产品的自定义元数据

为什么需要 Tekton Chains

软件供应链安全挑战

在传统的软件开发和交付流水线中，确保供应链中工件的完整性和安全性面临诸多挑战：

缺乏可追溯性：没有适当的溯源信息，难以验证工件的来源及构建方式
篡改风险：工件可能在多个阶段被修改而不被发现
验证困难：工件的消费者无法可靠地验证其真实性
合规挑战：组织难以满足日益严格的软件供应链安全法规要求

这些挑战导致了诸如 SolarWinds 等高调的供应链攻击事件，恶意代码被植入构建过程中，影响了成千上万的组织。

Tekton Chains 的解决方案

Tekton Chains 通过以下方式应对这些挑战：

自动生成溯源：捕获构建过程的详细元数据
加密签名：确保溯源数据的完整性和真实性
标准化格式：支持行业标准格式，如 SLSA 溯源
灵活存储：提供多种溯源存储和检索选项
与现有工具集成：支持 Cosign、Syft、Trivy、Kyverno、Rekor 及云 KMS 服务
- Cosign：用于容器镜像的签名、验证和管理签名的工具
- Syft：用于生成容器镜像 SBOM 的工具
- Trivy：用于生成容器镜像 SBOM 和漏洞扫描结果，以及漏洞扫描的工具
- Kyverno：Kubernetes 的策略引擎，可用于强制执行容器镜像的安全策略
- Rekor：用于签名工件的公共透明日志

通过实施 Tekton Chains，组织能够实现更高水平的供应链安全并满足 SLSA 合规要求。

优势

自动化：自动生成和签署溯源，无需人工干预
标准化：支持 SLSA 和 in-toto 等行业标准格式
灵活性：兼容多种签名机制和存储后端
集成性：无缝集成 Tekton Pipelines 生态系统
透明性：清晰展示工件的生产过程
合规性：帮助满足供应链安全的法规和行业要求

场景

场景 1：镜像签名验证

开发团队希望通过实施加密签名确保容器镜像的完整性。使用 Tekton Chains，可以自动为构建的镜像签名，并在部署过程中验证这些签名，防止未经授权的修改，确保只部署可信镜像。

场景 2：构建系统溯源验证

组织需要验证其构建过程的真实性并确保符合安全要求。通过实施 Tekton Chains，可以为容器镜像生成 SLSA 溯源，提供详细的构建信息，帮助维护安全且可审计的构建流程。

场景 3：源代码仓库验证

团队希望确保容器镜像是从可信的源代码仓库构建的。使用 Tekton Chains，可以自动生成包含源代码仓库信息和提交详情的溯源，帮助验证镜像是基于正确的源代码和特定提交构建的。

场景 4：漏洞扫描与验证

安全团队需要确保容器镜像在部署前无已知漏洞。通过结合漏洞扫描工具实施 Tekton Chains，可以自动扫描镜像安全问题并验证扫描结果，帮助维护安全的容器镜像仓库，防止漏洞镜像被部署。

场景 5：基础镜像和 SBOM 验证

组织希望维护容器镜像组件的完整清单，并确保使用可信的基础镜像。结合 SBOM 生成工具使用 Tekton Chains，可以自动生成和验证软件物料清单，帮助跟踪依赖关系并确保符合安全策略。

场景 6：许可证合规验证

法务团队需要确保容器镜像中的所有软件组件符合许可证要求。通过结合 SBOM 验证实施 Tekton Chains，可以自动检查镜像中所有组件的许可证，帮助维护软件许可合规，避免潜在法律风险。

场景 7：无密钥签名验证

开发团队希望实现零信任签名方式，无需管理签名密钥。使用支持无密钥签名的 Tekton Chains，可以自动使用临时密钥和透明日志签署工件，消除密钥管理负担，同时保持强大的安全保障。

约束与限制

Kubernetes 依赖：需要安装了 Tekton Pipelines 的 Kubernetes 集群
配置复杂性：需要正确配置 type hinting 以确保溯源准确
密钥管理：签名密钥的安全管理至关重要
存储需求：溯源和签名需要额外存储空间
性能影响：签名和存储溯源会增加构建过程的开销

原理

Tekton Chains 的工作方式

Tekton Chains 通过一个控制器观察 Kubernetes 集群中的 TaskRun 和 PipelineRun 资源。工作流程如下：

观察：控制器监视已完成的 TaskRun 和 PipelineRun
快照：运行完成后，Chains 对其状态进行快照
格式化：Chains 生成配置格式的溯源（如 SLSA）
签名：使用配置的方法对溯源进行加密签名
存储：将溯源和签名存储到配置的后端

Tekton Chains Workflow

溯源生成

Tekton Chains 使用 type hinting 理解构建过程的输入和输出信息，然后生成指定格式的溯源：

输入收集：通过 type hint 识别输入工件
构建过程捕获：记录构建环境和步骤的详细信息
输出识别：通过 type hint 识别输出工件
溯源组装：将所有信息组装成标准化格式

签名过程

Tekton Chains 支持多种签名方法以满足不同安全需求：

密钥检索：从配置的来源获取签名密钥
载荷准备：准备待签名的溯源数据
签名生成：生成加密签名
验证数据：包含验证所需的额外数据

配置示例

基础 SLSA v1.0 配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: chains-config
  namespace: tekton-chains
data:
  artifacts.taskrun.format: "slsa/v1"
  artifacts.taskrun.storage: "oci"
  artifacts.taskrun.signer: "x509"
  artifacts.pipelinerun.format: "slsa/v1"
  artifacts.pipelinerun.storage: "oci"
  artifacts.pipelinerun.signer: "x509"
  artifacts.oci.format: "simplesigning"
  artifacts.oci.storage: "oci"
  artifacts.oci.signer: "x509"

Type Hinting

TIP

更多关于 type hinting 的详细信息，请参见 Tekton Chains Type Hinting 文档。

Type Hinting 是 Tekton Chains 中的一种特殊机制，通过特定命名约定帮助 Chains 理解 PipelineRun/TaskRun 中的输入和输出工件。

目的

帮助 Chains 正确识别和记录构建过程中的输入和输出工件
生成准确的 SLSA 溯源认证
确保构建过程的可追溯性和完整性

指定输入和输出工件有多种方式：

1. CHAINS-GIT_URL 和 CHAINS-GIT_COMMIT 组合

Git 仓库信息的特殊 type hint
用于跟踪源代码仓库详情
有助于生成源代码的溯源

results:
  - name: CHAINS-GIT_URL
    type: string
  - name: CHAINS-GIT_COMMIT
    type: string

TaskRun 示例

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: git-clone
spec:
  taskSpec:
    params:
      - name: url
        description: 要克隆的仓库 URL。
        type: string
        default: "https://github.com/tektoncd/pipeline"
      - name: revision
        description: 要检出的版本（分支、标签、sha、ref 等）。
        type: string
        default: "main"
    results:
      - name: CHAINS-GIT_URL
        type: string
        description: 此任务获取的精确 URL。
      - name: CHAINS-GIT_COMMIT
        type: string
        description: 此任务获取的精确提交 SHA。
    steps:
      - name: dummy-clone
        image: bash:latest
        script: |
          #!/usr/bin/env bash
          echo -n "https://github.com/tektoncd/pipeline" | tee $(results.CHAINS-GIT_URL.path)
          echo -n "7f2f46e1b97df36b2b82d1b1d87c81b8b3d21601" | tee $(results.CHAINS-GIT_COMMIT.path)

2. *ARTIFACT_INPUTS

注意：

* 表示任意表达式

用于指定影响构建过程的输入工件
有助于跟踪依赖和源材料

results:
  - name: first-ARTIFACT_INPUTS
    type: object
    properties:
      uri: {}
      digest: {}

TaskRun 示例

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: git-clone
spec:
  taskSpec:
    params:
      - name: url
        description: 要克隆的仓库 URL。
        type: string
        default: "https://github.com/tektoncd/pipeline"
      - name: revision
        description: 要检出的版本（分支、标签、sha、ref 等）。
        type: string
        default: "main"
    results:
      - name: source_repo_ARTIFACT_INPUTS
        description: 源代码仓库工件
        type: object
        properties:
          uri: {}
          digest: {}
    steps:
      - name: dummy-clone
        image: bash:latest
        script: |
          #!/usr/bin/env bash
          echo -n "{\"uri\":\"https://github.com/tektoncd/pipeline\", \"digest\":\"sha1:7f2f46e1b97df36b2b82d1b1d87c81b8b3d21601\"}" > $(results.source_repo_ARTIFACT_INPUTS.path)

3. IMAGE_URL 和 IMAGE_DIGEST 组合

results:
  - name: first-image-IMAGE_URL
    type: string
  - name: first-image-IMAGE_DIGEST
    type: string

TaskRun 示例

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: image-build
spec:
  taskSpec:
    results:
      - name: first-image-IMAGE_URL
        type: string
        description: 构建的 OCI 镜像的精确 URL。
      - name: first-image-IMAGE_DIGEST
        type: string
        description: 构建的 OCI 镜像的算法和摘要。
    steps:
      - name: dummy-build
        image: bash:latest
        script: |
          #!/usr/bin/env bash
          echo -n "gcr.io/foo/bar" | tee $(results.first-image-IMAGE_URL.path)
          echo -n "sha256:586789aa031fafc7d78a5393cdc772e0b55107ea54bb8bcf3f2cdac6c6da51ee" | tee $(results.first-image-IMAGE_DIGEST.path)

4. IMAGES

可指定多个镜像，使用逗号或换行分隔
每个镜像必须包含完整的摘要

results:
  - name: IMAGES
    type: string

TaskRun 示例

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: image-build
spec:
  taskSpec:
    results:
      - name: IMAGES
        description: 多个镜像工件
        type: string
    steps:
      - name: dummy-build
        image: bash:latest
        script: |
          #!/usr/bin/env bash
          echo -n "img1@sha256:digest1, img2@sha256:digest2" | tee $(results.IMAGES.path)

5. ARTIFACT_URI / ARTIFACT_DIGEST 组合

类似于 IMAGE_URL/IMAGE_DIGEST，但命名不同
用于指定工件位置及其摘要

results:
  - name: first-ARTIFACT_URI
    type: string
  - name: first-ARTIFACT_DIGEST
    type: string

6. *ARTIFACT_OUTPUTS

使用对象类型结果
必须包含 uri 和 digest 字段

results:
  - name: first-ARTIFACT_OUTPUTS
    type: object
    properties:
      uri: {}
      digest: {}

TaskRun 示例

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: image-build
spec:
  taskSpec:
    results:
      - name: first-ARTIFACT_OUTPUTS
        description: 第一个构建的工件
        type: object
        properties:
          uri: {}
          digest: {}
    steps:
      - name: dummy-build
        image: bash:latest
        script: |
          #!/usr/bin/env bash
          echo -n "{\"uri\":\"gcr.io/foo/bar\", \"digest\":\"sha256:586789aa031fafc7d78a5393cdc772e0b55107ea54bb8bcf3f2cdac6c6da51ee\"}" > $(results.first-ARTIFACT_OUTPUTS.path)

重要参数

存储配置

存储后端决定了溯源和签名的存储位置，这对于确保溯源在验证时可访问至关重要。

使用场景

Tekton 存储：适用于调试和内部验证
OCI 存储：适合与容器镜像一起存储溯源
GCS/DocDB 存储：适合集中存储和管理

配置示例

artifacts.taskrun.storage: "tekton,oci"
artifacts.pipelinerun.storage: "tekton"
artifacts.oci.storage: "oci"

签名配置

签名配置决定了溯源的加密签名方式，是验证其真实性的关键。

使用场景

x509：标准证书签名
KMS：基于云的密钥管理，增强安全性
Keyless：使用临时密钥的零信任签名

配置示例

artifacts.taskrun.signer: "x509"
artifacts.pipelinerun.signer: "x509"
artifacts.oci.signer: "x509"

Operator

管道

Triggers

Results

#了解 Tekton Chains

#目录

#术语表

#为什么需要 Tekton Chains

#软件供应链安全挑战

#Tekton Chains 的解决方案

#优势

#场景

#场景 1：镜像签名验证

#场景 2：构建系统溯源验证

#场景 3：源代码仓库验证

#场景 4：漏洞扫描与验证

#场景 5：基础镜像和 SBOM 验证

#场景 6：许可证合规验证

#场景 7：无密钥签名验证

#约束与限制

#原理

#Tekton Chains 的工作方式

#溯源生成

#签名过程

#配置示例

#基础 SLSA v1.0 配置

#Type Hinting

#1. CHAINS-GIT_URL 和 CHAINS-GIT_COMMIT 组合

#2. *ARTIFACT_INPUTS

#3. *IMAGE_URL 和 *IMAGE_DIGEST 组合

#4. IMAGES

#5. *ARTIFACT_URI / *ARTIFACT_DIGEST 组合

#6. *ARTIFACT_OUTPUTS

#重要参数

#存储配置

#使用场景

#配置示例

#签名配置

#使用场景

#配置示例

#参考资料

了解 Tekton Chains

目录

术语表

为什么需要 Tekton Chains

软件供应链安全挑战

Tekton Chains 的解决方案

优势

场景

场景 1：镜像签名验证

场景 2：构建系统溯源验证

场景 3：源代码仓库验证

场景 4：漏洞扫描与验证

场景 5：基础镜像和 SBOM 验证

场景 6：许可证合规验证

场景 7：无密钥签名验证

约束与限制

原理

Tekton Chains 的工作方式

溯源生成

签名过程

配置示例

基础 SLSA v1.0 配置

Type Hinting

1. CHAINS-GIT_URL 和 CHAINS-GIT_COMMIT 组合

2. *ARTIFACT_INPUTS

3. IMAGE_URL 和 IMAGE_DIGEST 组合

4. IMAGES

5. ARTIFACT_URI / ARTIFACT_DIGEST 组合

6. *ARTIFACT_OUTPUTS

重要参数

存储配置

使用场景

配置示例

签名配置

使用场景

配置示例

参考资料