4. 签名链路架构：开发环境、CI/CD流水线、制品仓库、签名服务、验证节点
制品签名链路并非单一工具或步骤，而是贯穿软件交付全生命周期的安全基础设施。在IDP（内部开发者平台）黄金路径中，签名链路必须与开发环境、CI/CD流水线、制品仓库、签名服务及验证节点深度集成，形成一条从代码提交到生产部署的“信任链”。本章将逐一拆解这五个核心环节的架构职责与交互关系。
4.1 签名链路总体架构
下图展示了签名链路在IDP黄金路径中的完整拓扑。每个环节承担特定的安全职能，并通过标准化的API或协议进行通信。
4.2 各环节职责与关键技术
下表详细定义了五个核心环节在签名链路中的具体职责、输入/输出以及典型技术选型。
| 环节 | 核心职责 | 输入 | 输出 | 典型技术 |
|---|---|---|---|---|
| 开发环境 | 生成开发者签名（可选）、注入元数据、本地构建验证 | 源代码、开发者私钥 | 带有开发者签名的构建产物 | GPG、cosign（本地模式）、Sigstore 客户端 |
| CI/CD 流水线 | 触发签名流程、传递上下文、集成验证结果 | 构建产物、流水线上下文（分支、提交ID） | 签名请求、部署准入决策 | Tekton、Jenkins、GitHub Actions、Argo Workflows |
| 签名服务 | 密钥管理、执行签名、记录审计日志 | 签名请求（含摘要、元数据） | 数字签名（如 JWT、PKCS#7、Sigstore Bundle） | Vault、AWS KMS、Azure Key Vault、cosign（服务模式） |
| 制品仓库 | 存储已签名制品、提供签名验证元数据 | 已签名制品、签名文件（.sig/.att） | 可验证的制品版本 | Harbor、Artifactory、Docker Registry、OSS |
| 验证节点 | 验证签名链、执行策略、阻断非法制品 | 制品、签名、策略（如 Rego） | 验证通过/拒绝决策 | Kyverno、OPA、cosign verify、Ratify |
4.3 开发环境：信任链的起点
开发环境是签名链路的“第一公里”。在黄金路径实践中，开发环境主要负责两件事：本地构建完整性校验和开发者身份绑定。
- 本地构建校验：开发者提交代码前，IDE或本地脚本自动计算制品摘要（SHA256），并生成一个“开发阶段签名”。该签名不用于生产，但可作为CI/CD流水线判断“代码是否经过本地审查”的依据。
- 元数据注入：在构建产物中注入
BUILD_USER、BUILD_TIMESTAMP、COMMIT_SHA等标签，确保后续环节可追溯。
最佳实践： 开发环境签名使用临时密钥（ephemeral key），密钥生命周期仅持续到CI/CD流水线开始。避免开发者私钥长期暴露在本地磁盘。
4.4 CI/CD 流水线：签名编排中枢
CI/CD流水线是签名链路的编排中枢。它不直接执行签名，而是负责：
- 触发签名请求：在构建阶段完成后，流水线将制品摘要、流水线上下文（PipelineRun ID、触发事件）打包成签名请求，发送至签名服务。
- 传递信任上下文：流水线将自身身份（如ServiceAccount ）附加到请求中，签名服务据此验证请求来源是否合法。
- 处理验证结果：流水线等待验证节点的回调，若验证失败则中断部署并发送告警。
# 示例：Tekton Task 中触发签名请求的片段
apiVersion: tekton.dev/v1
kind: Task
spec:
steps:
- name: request-signature
image: bitnami/kubectl:latest
script: |
# 计算制品摘要
DIGEST=$(sha256sum /workspace/output/artifact.bin | awk '{print $1}')
# 调用签名服务 API
curl -s -X POST https://signature-service.internal/sign \
-H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/)" \
-d '{"digest": "'$DIGEST'", "pipeline_run_id": "'$(params.pipeline-run-id)'"}'4.5 签名服务：密钥与签名核心
签名服务是整个链路的安全核心。它必须满足以下架构要求：
- 密钥分层管理：根密钥（Root Key）离线存储，签名密钥（Signing Key）定期轮换，且签名密钥由根密钥签名授权。
- 无状态签名：签名服务不存储制品，仅接收摘要并返回签名，降低数据泄露风险。
- 审计日志：每次签名操作记录请求来源、制品摘要、时间戳，支持事后审计。
关键指标： 签名服务单次签名延迟应 < 200ms（P99），支持每秒至少 1000 次签名请求（1000 TPS），以满足大规模CI/CD并发需求。
4.6 制品仓库：签名与制品的绑定
制品仓库不仅是存储中心，更是签名元数据的关联中心。每个制品版本必须附带以下签名相关文件：
| 文件类型 | 命名规范 | 内容说明 |
|---|---|---|
| 签名文件 | artifact.bin.sig |
制品摘要的数字签名（Base64编码） |
| 证书链文件 | artifact.bin.cert |
签名证书或公钥（可选，用于离线验证） |
| 断言文件 | artifact.bin.att |
in-toto 断言，包含流水线元数据、材料清单 |
| 摘要文件 | artifact.bin.sha256 |
制品摘要明文，便于快速校验 |
4.7 验证节点：信任链的最终守卫
验证节点是签名链路的最后一环，通常部署在Kubernetes集群中作为准入控制器（Admission Controller）或运行时Sidecar。其验证流程如下：
- 拉取制品与签名：从制品仓库获取制品及其关联的签名文件、断言文件。
- 证书链校验：验证签名证书是否由受信任的根证书签发，且未过期或吊销。
- 摘要比对：重新计算制品摘要，与签名中的摘要比对，确保制品未被篡改。
- 策略执行：基于OPA/Kyverno策略，检查断言中的流水线上下文是否满足安全基线（如：必须经过代码审查、必须来自受保护分支）。
- 决策输出：返回验证通过/拒绝，CI/CD流水线根据结果决定是否继续部署。
4.8 链路交互协议与数据流
签名链路各环节之间的通信必须采用标准化协议，确保互操作性。推荐使用以下协议：
- CI/CD → 签名服务：gRPC 或 HTTPS REST，请求体包含制品摘要（Base64编码）、流水线上下文（JSON）。
- 签名服务 → 制品仓库：通过制品仓库的API（如Harbor API）直接上传签名文件，或返回签名后由CI/CD代为上传。
- 验证节点 → 制品仓库：OCI Distribution Spec 或 S3/GCS API，拉取制品及关联签名文件。
- 验证节点 → CI/CD：Webhook 回调或消息队列（如Kafka），传递验证结果。
安全警告： 签名请求必须携带流水线的身份令牌（如Kubernetes ServiceAccount ），签名服务需验证令牌有效性，防止未授权签名请求。禁止使用硬编码的。
4.9 架构决策记录（ADR）示例
在黄金路径签名链路设计中，以下架构决策需要团队达成共识：
| 决策编号 | 决策项 | 选择方案 | 理由 |
|---|---|---|---|
| ADR-001 | 签名服务部署模式 | 独立服务（非嵌入CI/CD） | 解耦密钥管理，支持多流水线共享，便于审计 |
| ADR-002 | 签名算法 | ECDSA P-384 | 性能与安全性平衡，符合NIST SP 800-57 |
| ADR-003 | 验证节点位置 | Kubernetes Admission Webhook | 在部署前拦截，无需修改应用代码 |
| ADR-004 | 密钥轮换策略 | 每90天自动轮换，保留前一个密钥用于验证 | 减少密钥泄露影响范围，同时保证旧制品可验证 |
通过以上架构设计，IDP黄金路径的签名链路实现了从开发环境到生产环境的端到端信任传递，为后续的自动化测试验证奠定了坚实的基础。