📚 课程目录第2章 Sigstore核心组件解析

2. Sigstore 核心组件解析：Cosign、Fulcio、Rekor 及其协同机制

Sigstore 并非单一工具，而是一套由三个核心组件构成的开放签名基础设施。在 API 延迟诊断场景中，理解这三个组件的职责与协作关系，是构建可观测标签体系与策略即代码（Policy-as-Code）断言的前提。本节将逐一解析 Cosign、Fulcio 和 Rekor，并通过架构图与表格阐明其协同工作流。

2.1 组件总览与职责对比

组件	全称 / 类型	核心职责	在延迟诊断场景中的角色
Cosign	签名 & 验证客户端	对容器镜像、Blob、文档等工件进行签名与验证；支持密钥对、密钥管理服务（KMS）及硬件安全模块（HSM）	为延迟诊断的 API 契约（如 OpenAPI 规范、延迟 SLO 定义文件）生成签名，并附加可观测标签
Fulcio	证书颁发机构（CA）	基于 OIDC（OpenID Connect）身份签发短期 X.509 证书，将用户/工作负载身份绑定到公钥	为诊断流水线中的服务身份（如 Kubernetes ServiceAccount、GitHub Actions Workflow）签发临时证书，确保证明链可审计
Rekor	透明日志（Transparency Log）	不可篡改的签名事件账本，记录所有签名元数据与证书信息，支持后续审计与验证	存储延迟诊断策略的签名记录，提供全局可观测的签名时间戳与证书指纹，用于事后取证与合规报告

关键概念： Sigstore 的“无密钥”签名模式并非真的没有密钥，而是通过 Fulcio 签发的短期证书替代传统长期密钥管理，降低密钥泄露风险。在延迟诊断场景中，这意味着每次策略签名都可以绑定到具体的 CI/CD 执行上下文。

2.2 Cosign：签名与验证的执行者

Cosign 是 Sigstore 生态中最贴近用户的前端工具。它支持对多种工件类型进行签名，并将签名结果以 OCI（Open Container Initiative）制品的形式存储在容器镜像仓库中，或作为独立附件存储。

2.2.1 核心操作流程

签名（Sign）： 用户指定目标工件（如 my-api-spec.yaml），Cosign 调用 Fulcio 获取短期证书，使用私钥对工件摘要进行签名，并将签名与证书一并上传至 Rekor。
验证（Verify）： 验证方从 Rekor 获取签名记录，使用 Fulcio 证书链验证签名有效性，同时检查证书是否在有效期内且未被吊销。
附加标签（Attach）： Cosign 支持通过 --attachment-tag-prefix 参数为签名附加自定义标签，这些标签可直接映射为可观测性指标中的维度。

延迟诊断场景示例：

# 对延迟 SLO 策略文件进行签名，并附加环境与版本标签
cosign sign --attachment-tag-prefix "diagnosis-latency-slo" \
  --oidc-issuer "https://.actions.githubusercontent.com" \
  my-registry/latency-policies:v1.2.3

# 验证签名并提取标签
cosign verify --attachment-tag-prefix "diagnosis-latency-slo" \
  my-registry/latency-policies:v1.2.3

2.3 Fulcio：基于 OIDC 的身份证书颁发

Fulcio 消除了传统 PKI（公钥基础设施）中繁琐的证书申请与续期流程。它通过 OIDC 协议信任来自 GitHub、GitLab、Google、Microsoft 等身份提供者的 ID ，并据此签发符合 X.509 v3 标准的短期证书（通常有效期为 10 分钟）。

证书内容： 证书中包含用户的 OIDC 身份信息（如 email、sub）、公钥、以及 Fulcio 的根 CA 签名。
安全边界： 短期证书过期后即使私钥泄露，攻击者也无法伪造历史签名。这符合延迟诊断场景中“最小权限”与“临时凭证”的安全原则。
审计字段： 证书的 Subject Alternative Name（SAN）字段可直接作为可观测标签中的 identity 维度，用于追踪哪个服务或流水线发起了策略签名。

2.4 Rekor：不可篡改的签名账本

Rekor 透明日志是 Sigstore 信任链的基石。所有签名事件（包括签名哈希、证书、签名时间戳）都会被追加到 Merkle 树结构中，任何人都可以查询和验证日志的完整性。

Rekor 条目字段	说明	可观测标签映射
`Body`	签名事件的原始内容（Base64 编码），包含工件哈希与签名值	`signature_hash`
`IntegratedTime`	条目被写入日志的 Unix 时间戳	`signing_timestamp`
`LogIndex`	条目在 Merkle 树中的唯一索引	`rekor_log_index`
`Attestation`	可选的附加声明（如 DSSE 信封），用于携带策略元数据	`policy_attestation`

注意： Rekor 是公开可查询的（默认使用公共实例 rekor.sigstore.dev）。对于敏感的内部延迟诊断策略，建议部署私有 Rekor 实例或使用 --no-rekor 标志（但会降低审计能力）。

2.5 协同工作流：从签名到验证的完整链路

下图展示了 Cosign、Fulcio 和 Rekor 在 API 延迟诊断策略签名场景中的完整交互流程。

2.6 协同工作的关键时序与数据流

上述架构图展示了五个核心步骤，下面以表格形式细化每一步的数据流与安全属性：

步骤	发起方	接收方	传输数据	安全属性
1. 发起签名请求	用户/CI	Cosign	工件路径、OIDC ID 、签名参数	mTLS（若启用）
2. 请求 OIDC 证书	Cosign	Fulcio	ID 、公钥、挑战值	OIDC 令牌验证、短期凭证
3. 返回短期证书	Fulcio	Cosign	X.509 证书（含 SAN、有效期、Fulcio 签名）	证书链验证、10 分钟有效期
4. 上传签名记录	Cosign	Rekor	工件哈希、签名值、证书、可选声明	Merkle 树追加、不可篡改
5. 存储签名 + 标签	Cosign	OCI 仓库	签名附件、可观测标签（如 `env=prod`）	仓库访问控制、标签不可变性

2.7 在延迟诊断场景中的协同价值

将 Sigstore 三组件应用于 API 延迟诊断，可以实现以下可观测性增强：

不可抵赖的签名时间戳： Rekor 的 IntegratedTime 字段可作为延迟 SLO 策略生效时间的权威证据，避免“策略何时部署”的争议。
身份与策略绑定： Fulcio 证书中的 OIDC 身份信息可直接映射为 Prometheus 标签（如 signed_by="team-alpha"），用于按团队聚合延迟违规事件。
自动化策略验证： 在 CI/CD 流水线中集成 Cosign verify 步骤，确保只有经过签名的延迟策略文件才能被加载到诊断引擎中，防止配置篡改。
审计与合规： Rekor 的透明日志为安全团队提供全局可查询的签名事件视图，满足 SOC2、PCI-DSS 等合规要求中的“变更审计”控制点。

实践建议： 在部署 Sigstore 时，建议将 Cosign 的 --attachment-tag-prefix 与 Rekor 的 --rekor-url 参数通过环境变量注入，以便在可观测性平台中统一采集 sigstore_* 指标。例如：

export COSIGN_ATTACHMENT_TAG_PREFIX="diagnosis-latency-slo"
export REKOR_URL="https://rekor.internal.example.com"