2. IDP 流水线基础:CI/CD 流水线架构、制品仓库角色与签名服务集成点

2.1 CI/CD 流水线核心架构

在内部开发者平台(IDP)中,CI/CD 流水线是制品签名链路的执行载体。一条标准的 IDP 流水线通常包含以下四个阶段,每个阶段都对应签名链路的特定操作点:

关键原则:签名操作应尽可能靠近制品生成点,避免在流水线末端对已签名制品进行二次修改,否则将导致签名失效。
IDP CI/CD 流水线四阶段架构 ① 代码提交 Git Push / PR Merge 触发 Webhook ② 构建与测试 编译 / 单元测试 生成构建产物 ③ 制品签名与推送 调用签名服务 推送至制品仓库 ④ 部署与验证 签名验证 灰度发布 流水线签名集成点说明 • 阶段②结束后,构建产物(如 JAR、Docker 镜像、NPM 包)进入签名准备状态。 • 阶段③是签名链路的核心集成点:流水线调用外部签名服务(如 Sigstore、JWT 签名网关), 对制品摘要(Digest)进行签名,并将签名元数据一同推送至制品仓库。 • 阶段④在部署前执行签名验证,确保制品未被篡改且来源可信。

2.2 制品仓库(Artifact Repository)的角色

制品仓库是 IDP 中存储、版本化、分发构建产物的核心基础设施。在签名链路中,制品仓库承担以下三个关键角色:

角色 说明 签名链路中的职责
存储中心 统一存放所有构建产物及其元数据 存储签名文件(.sig / .asc)、签名证书、摘要文件
版本管理 支持制品版本化、快照与发布隔离 回滚时通过版本标签定位历史签名制品
分发网关 为下游部署环境提供制品拉取接口 部署时同时拉取制品与签名文件,供验证组件使用
推荐实践:使用支持“不可变标签”(Immutable Tag)的制品仓库(如 Harbor、Artifactory),防止已签名制品被覆盖导致签名链断裂。

2.3 签名服务集成点

签名服务是 IDP 流水线中独立的安全组件,通常以 HTTP API 或 gRPC 接口暴露。流水线在以下三个集成点与签名服务交互:

  1. 签名请求点(Sign Request Point):流水线在构建阶段结束后,将制品摘要(SHA256)发送至签名服务,获取签名结果。
  2. 验证请求点(Verify Request Point):部署前,流水线将制品摘要与签名文件发送至签名服务,验证签名有效性。
  3. 回滚恢复点(Rollback Recovery Point):回滚时,流水线从制品仓库拉取历史签名制品及其签名文件,重新执行验证。
签名服务集成点架构 CI/CD 流水线 构建 / 部署 / 回滚 签名服务 Sign / Verify / Rotate 制品仓库 存储 / 版本 / 分发 三个集成点 ① 签名请求点:流水线 → 签名服务(制品摘要 → 签名结果) ② 验证请求点:流水线 → 签名服务(制品摘要 + 签名 → 验证结果) ③ 回滚恢复点:流水线 → 制品仓库 → 签名服务(历史制品 + 历史签名 → 重新验证)

2.4 签名链路中的关键元数据

在流水线中,每个签名制品都关联一组元数据,用于支持回滚时的签名验证与溯源:

元数据字段 示例值 回滚用途
制品 Digest sha256:a1b2c3d4e5f6... 唯一标识制品内容,回滚时对比验证
签名时间戳 2025-03-21T10:30:00Z 判断签名是否在证书有效期内
签名证书指纹 SHA1: 12:34:56:78:9A:BC... 回滚时确认签名证书未被吊销
流水线构建 ID build-20250321-001 关联回滚目标与历史构建记录
注意:回滚时如果制品仓库中的签名文件丢失或与制品 Digest 不匹配,必须拒绝部署。建议在制品仓库中启用“签名文件强制校验”策略。

2.5 流水线签名集成示例(伪代码)

以下是一个简化的流水线阶段定义,展示签名服务集成点的调用方式:

# 流水线阶段定义(伪代码)
stages:
  - build
  - sign
  - push
  - deploy

sign:
  stage: sign
  script:
    - DIGEST=$(sha256sum artifact.bin | awk '{print $1}')
    - SIGNATURE=$(curl -X POST https://sign-service.internal/sign \
        -H "Authorization: Bearer ${SIGN_}" \
        -d "{\"digest\": \"${DIGEST}\"}")
    - echo "${SIGNATURE}" > artifact.bin.sig
  artifacts:
    paths:
      - artifact.bin.sig

deploy:
  stage: deploy
  script:
    - DIGEST=$(sha256sum artifact.bin | awk '{print $1}')
    - VERIFY_RESULT=$(curl -X POST https://sign-service.internal/verify \
        -H "Authorization: Bearer ${SIGN_}" \
        -d "{\"digest\": \"${DIGEST}\", \"signature\": \"$(cat artifact.bin.sig)\"}")
    - if [ "${VERIFY_RESULT}" != "valid" ]; then exit 1; fi
    - ./deploy.sh artifact.bin

上述示例中,sign 阶段对应签名请求点,deploy 阶段对应验证请求点。回滚时,流水线会拉取历史构建的 artifact.bin 与 artifact.bin.sig,重新执行 deploy 阶段的验证逻辑。