Cosign策略升级日志关联与异常根因定位 - 第2节

2.1 Cosign 工作原理与核心架构

Cosign 是 Sigstore 项目下的容器镜像签名工具，旨在解决“谁签的、签的什么、签名是否可信”三个核心问题。其工作原理围绕无密钥（Keyless）签名与透明日志（Transparency Log）两条主线展开，在策略升级窗口的异常样本分析中，理解 Cosign 的底层数据流是根因定位的前提。

2.1.1 签名流程（三步模型）

1. 身份获取：用户通过 OIDC 提供商（GitHub、Google、Microsoft）获取短期身份令牌。
2. 签名生成：Cosign 使用 Fulcio 根证书颁发机构签发短期证书，私钥仅存于内存，签名后立即销毁。
3. 日志记录：签名负载（镜像摘要、证书、签名值）被提交至 Rekor 透明日志，返回一个唯一的 UUID 和 SignedEntryTimestamp。

2.1.2 验证流程（四步校验）

2.2 签名与验证机制详解

Cosign 支持两种签名模式：密钥对签名（传统模式）和 Keyless 签名（默认模式）。在策略升级窗口的异常分析中，Keyless 模式因其依赖外部 OIDC 和 Rekor 服务，更容易出现网络超时、证书吊销等异常。

2.2.1 密钥对签名（传统模式）

• 私钥管理：用户生成 cosign.key 和 cosign.pub，私钥需安全存储。
• 签名命令：cosign sign --key cosign.key <镜像>
• 验证命令：cosign verify --key cosign.pub <镜像>
• 适用场景：离线环境、内部私有仓库、策略升级窗口内无法访问公网 OIDC 的场景。

2.2.2 Keyless 签名（默认模式）

• 身份绑定：签名证书中嵌入 OIDC 身份信息（邮箱、issuer）。
• 证书时效：证书有效期通常为 10 分钟，过期后无法单独用于验证。
• 验证依赖：必须同时查询 Rekor 日志获取证书链和签名时间戳。
• 异常特征：策略升级窗口内若 OIDC 提供商变更策略（如 GitHub OAuth 范围调整），会导致新签名无法被旧策略验证。

# Keyless 签名示例
cosign sign <镜像>
# 输出示例：
# Pushing signature to: registry.example.com/nginx@sha256:abc...sig
# Successfully verified in Rekor at index: 1234567

# Keyless 验证示例
cosign verify <镜像>
# 验证通过时返回证书信息与 Rekor 条目

2.3 Cosign 在容器镜像安全中的角色

Cosign 在容器镜像安全体系中承担签名生成者与验证执行者双重角色，是策略升级窗口内安全基线的核心组件。其角色可归纳为以下三个维度：

2.4 Cosign 工作流架构图

下图展示了 Cosign 在 Keyless 模式下的完整工作流，包含签名、日志记录、验证三个核心阶段。该架构图是分析策略升级窗口内日志关联异常的基础框架。

2.5 签名数据结构与日志关联字段

在策略升级窗口的异常分析中，需要重点关注 Cosign 签名数据中的以下字段，它们是日志关联与根因定位的关键线索：

// Cosign 签名负载示例（简化 JSON）
{
  "critical": {
    "image": {
      "digest": "sha256:abc123..."
    },
    "identity": {
      "issuer": "https://github.com/login/oauth",
      "subject": "user@example.com"
    }
  },
  "tlogEntry": {
    "logIndex": 1234567,
    "integratedTime": 1699000000
  }
}