1. 课程导论：Sigstore 与策略即代码概述、资源配额模型漂移告警的背景与挑战
1.1 为什么需要 Sigstore 与策略即代码？
在云原生软件供应链中，从代码提交到生产部署的每个环节都可能引入安全风险。传统的签名与验证机制（如 GPG）存在密钥管理复杂、轮换困难、验证分散等问题。Sigstore 作为新一代无密钥签名基础设施，结合策略即代码（Policy-as-Code）引擎，能够将安全策略从人工审核转变为自动化、可审计的代码化规则，从而有效应对资源配额模型漂移等运行时异常。
核心观点： Sigstore 解决了“谁来签、怎么签、如何验证”的信任链问题；策略即代码则解决了“签完后是否合规、是否持续合规”的治理问题。两者结合，为资源配额模型漂移告警的复测提供了可重复、可追溯的技术基础。
1.2 Sigstore 核心组件与信任模型
Sigstore 由三个主要组件构成，形成完整的签名-验证闭环：
| 组件 | 功能 | 在漂移复测中的角色 |
|---|---|---|
| Fulcio | 短期证书颁发机构（CA），基于 OIDC 身份签发证书 | 为每次签名提供临时身份凭证，确保签名者身份可审计 |
| Rekor | 透明日志，记录所有签名元数据 | 提供不可篡改的签名记录，用于漂移发生前后的签名比对 |
| Cosign | 签名与验证 CLI 工具 | 执行策略检查，触发漂移告警后的重新签名与验证 |
1.3 资源配额模型漂移告警的背景
在 Kubernetes 等云原生平台中，资源配额（Resource Quota）定义了命名空间级别的 CPU、内存、存储等上限。当实际资源使用量或配置与预期模型产生偏差时，即发生配额模型漂移。这种漂移可能由以下原因引发：
- 配置变更未审计： 运维人员手动调整配额，未经过策略审批流程。
- 应用版本升级： 新版本 workload 的资源请求/限制发生变化，导致配额模型失效。
- 多集群不一致： 同一应用在不同集群的配额配置不同步，产生环境间漂移。
- 自动扩缩容副作用： HPA/VPA 调整副本数或资源规格，超出原始配额模型范围。
漂移告警的挑战： 传统告警仅通知“配额已变更”，但无法回答“变更是否合规”“变更由谁触发”“如何恢复到合规状态”。Sigstore + 策略即代码的复测流程，正是为了解决这些根本性问题。
1.4 策略即代码在漂移复测中的关键作用
策略即代码将安全与合规规则以声明式代码形式管理，在漂移复测流程中承担以下职责：
| 策略类型 | 示例规则 | 漂移检测方式 |
|---|---|---|
| 配额边界策略 | 命名空间 CPU 配额不得超过 16 核 | 实时比对当前配额与策略基线 |
| 签名绑定策略 | 所有配额变更必须附带 Sigstore 签名 | 检查 Rekor 中是否存在对应签名记录 |
| 复测准入策略 | 漂移修复后必须重新签名并通过策略验证 | 触发 Cosign verify 并执行 OPA 规则 |
| 历史回溯策略 | 漂移前后签名状态必须可审计 | 查询 Rekor 日志获取时间线 |
1.5 本课程的学习目标与适用场景
通过本课程，您将掌握以下核心能力：
- 理解 Sigstore 签名模型： 掌握 Fulcio、Rekor、Cosign 在策略即代码中的集成方式。
- 编写资源配额策略： 使用 OPA/Rego 或 Kyverno 定义配额边界与漂移检测规则。
- 构建复测流水线： 设计从告警触发到策略验证、重新签名、复测通过的自动化流程。
- 审计与回溯： 利用 Rekor 透明日志追溯漂移历史，生成合规报告。
适用场景： 金融、医疗、政务等对资源配额合规性要求严格的行业；多集群、多租户环境下的配额治理；DevSecOps 流水线中的安全门禁集成。