📚 课程目录第4章 Project资源配额与权限

4. 制品签名链路概述：从代码提交到镜像签名验证的完整流程

在云原生多租户环境中，制品签名链路是保障供应链安全的核心防线。本章将完整拆解从开发者提交代码到生产环境验证镜像签名的全链路流程，明确每个环节的信任锚点、签名时机与验证边界，为后续压测场景中的容量基线校准提供流程上下文。

制品签名链路可划分为四个连续阶段，每个阶段完成一次信任状态的转换或增强：

阶段	起点	终点	信任锚点	签名/验证动作
① 代码提交与CI触发	开发者 Git Push	CI Pipeline 启动	Git Commit GPG 签名	验证提交者身份与代码完整性
② 镜像构建与签名	Docker Build 完成	镜像推送至 Registry	私钥签名 / KMS 签名	对镜像 Digest 进行 Cosign / Notation 签名
③ 部署策略与签名验证	Argo CD 检测到新镜像	Kubernetes 资源 Apply	公钥 / 策略引擎	验证签名是否匹配允许的镜像仓库与标签模式
④ 运行时持续验证	Pod 启动	准入控制器 / 审计日志	策略代理 (OPA / Kyverno)	运行时验证签名是否仍有效，记录审计事件

压测关注点： 阶段②和③是签名链路的性能瓶颈高发区。镜像签名操作涉及非对称加密计算，验证操作涉及公钥拉取与策略匹配，在高并发多租户场景下，签名吞吐量与验证延迟直接影响 Argo CD 的部署效率。

GPG 签名验证： Git 提交必须携带 GPG 签名，CI 系统（如 GitLab CI / GitHub Actions）在触发 Pipeline 前验证签名指纹是否在组织的信任公钥列表中。
SBOM 生成： CI 在构建前自动生成软件物料清单（SBOM），为后续签名提供可追溯的依赖清单。
触发条件： 仅当提交签名验证通过且分支策略匹配时，才触发镜像构建 Pipeline。

构建阶段： Dockerfile 执行多阶段构建，生成最终镜像 Digest（SHA256）。
签名时机： 镜像推送至 Registry 前，CI 使用 Cosign（Sigstore）或 Notation（Notary v2）对镜像 Digest 进行签名。
签名存储： 签名以 OCI 制品形式存储在 Registry 中，与镜像位于同一仓库，通过 Tag 或 Referrers API 关联。
密钥管理： 私钥由 KMS（如 AWS KMS、HashiCorp Vault）托管，CI 仅通过临时令牌调用签名接口，不接触原始私钥。

Argo CD 检测： Argo CD 通过 Webhook 或轮询检测到新镜像 Tag 或 Digest 更新。
签名验证触发： Argo CD 调用策略引擎（如 OPA / Kyverno）执行签名验证策略。
验证内容：
- 镜像 Digest 是否与签名中的 Digest 一致。
- 签名者身份是否在允许的信任列表中。
- 签名是否在有效期内（时间戳或 TUF 元数据）。
决策结果： 验证通过则继续部署；验证失败则拒绝 Apply，并记录审计事件。

下图展示了从代码提交到镜像签名验证的完整流程，包含关键节点与信任传递关系：

签名链路的本质是信任的逐级传递。每个阶段都建立在前一阶段的信任基础上，形成一条完整的信任链：

  信任链： Git GPG 签名 → CI 身份认证 → 镜像签名私钥 → 策略引擎公钥 → 运行时准入控制

安全边界定义：

在多租户环境中，签名链路需要额外考虑隔离性：

挑战	描述	影响
密钥隔离	每个租户使用独立的签名密钥，KMS 需支持租户级权限隔离	密钥管理复杂度上升，签名操作需携带租户上下文
策略冲突	不同租户的签名验证策略可能冲突（如允许的镜像仓库列表重叠）	策略引擎需支持租户级命名空间隔离
性能争抢	多个租户同时触发签名验证，KMS 和策略引擎成为共享瓶颈	验证延迟增加，影响 Argo CD 部署速度
审计隔离	签名验证日志需按租户分离，避免数据泄露	日志系统需支持租户标签和访问控制

压测前置条件： 在进行容量基线校准时，必须模拟多租户并发场景，分别测量每个租户的签名验证延迟和吞吐量，避免单租户测试掩盖共享资源争抢问题。

以下组件在签名链路中承担核心角色，压测前需确认版本兼容性：

版本不匹配可能导致签名格式解析失败、策略语法错误或性能退化，压测前应统一版本基线。