2. CI/CD 流水线基础架构
CI/CD 流水线是现代软件交付的核心自动化骨架。理解其基础架构，是后续进行权限矩阵安全测试与合规边界验证的前提。本章将拆解流水线的四大核心组件，并通过拓扑图展示其典型协作关系。
2.1 流水线核心组件
一条完整的 CI/CD 流水线通常由以下四个核心组件构成，每个组件都承载着特定的安全职责与权限边界。
| 组件 | 功能定义 | 安全关注点 |
|---|---|---|
| 代码仓库 | 存储源代码、配置文件、IaC 模板；触发流水线执行 | 分支保护、提交签名、密钥泄露扫描、访问控制 |
| 构建服务器 | 拉取代码、执行编译、运行测试、打包制品 | 构建环境隔离、临时凭证管理、依赖供应链风险 |
| 制品库 | 存储构建产物（镜像、JAR、NPM 包）；版本管理与分发 | 制品签名验证、访问权限、不可变版本策略、清理策略 |
| 部署环境 | 运行应用的目标环境（开发、测试、预发布、生产） | 环境隔离、部署审批、配置管理、运行时安全 |
安全视角提示： 每个组件之间的凭证传递是权限泄露的高发区。例如，构建服务器从代码仓库拉取代码时使用的 SSH Key 或 Token，其权限范围应严格限定为只读，且定期轮换。
2.2 典型流水线拓扑图
下图展示了一条从代码提交到生产部署的典型 CI/CD 流水线拓扑。该图清晰呈现了四个核心组件之间的数据流与触发关系，以及各阶段的安全控制点。
2.3 组件间的权限交互模型
在流水线中，权限并非孤立存在，而是通过凭证（Credential）在组件间传递。理解这个交互模型，是设计最小权限策略的基础。
- 代码仓库 → 构建服务器： 构建服务器使用 Deploy Key 或 Access Token 拉取代码。该凭证应仅具有目标仓库的 读取 权限。
- 构建服务器 → 制品库： 构建完成后，使用 CI Job Token 或 Service Account 推送制品。该凭证应仅具有目标制品库的 写入 权限。
- 制品库 → 部署环境： 部署工具（如 ArgoCD、Spinnaker）从制品库拉取制品。该凭证应仅具有 读取 权限，且通常绑定到特定项目或制品路径。
- 部署环境 → 基础设施： 部署工具需要访问 Kubernetes API 或云服务商 API。该凭证应使用 临时令牌 或 角色扮演 方式，避免使用长期有效的静态密钥。
常见权限陷阱： 许多团队在构建服务器中配置了具有仓库“写入”权限的 Token，以便在构建过程中自动打 Tag。这种做法风险极高——一旦构建服务器被攻陷，攻击者可以直接向代码仓库推送恶意代码。应优先使用 CI 平台的 API 或 Git 操作来创建 Tag，而非赋予构建服务器仓库写入权限。
2.4 流水线阶段与权限边界
流水线通常按阶段划分，每个阶段应运行在独立的上下文中，拥有不同的权限边界。下表展示了典型阶段及其权限要求。
| 流水线阶段 | 典型操作 | 所需权限 | 权限边界 |
|---|---|---|---|
| 检出 | git clone | 仓库读取 | 仅限当前分支 |
| 静态分析 | SAST、Lint | 代码读取 | 无需网络权限 |
| 构建 | 编译、打包 | 依赖下载、临时文件写入 | 仅限构建容器内 |
| 测试 | 单元测试、集成测试 | 测试数据库连接 | 仅限测试环境凭证 |
| 制品发布 | 推送镜像、上传包 | 制品库写入 | 仅限目标仓库路径 |
| 部署 | 更新 K8s 资源、运行脚本 | 目标环境 API 调用 | 仅限特定命名空间 |
2.5 流水线拓扑变体：多环境并行部署
在大型项目中，流水线拓扑可能演变为多环境并行部署模式。下图展示了这种变体，其中制品库作为单一可信源，同时向多个环境分发制品。
2.6 安全基线：组件权限最小化原则
基于上述架构分析，我们总结出以下安全基线，作为后续权限矩阵测试的输入条件。
- 凭证生命周期管理： 所有流水线凭证必须设置过期时间，最长不超过 90 天。优先使用临时凭证（如 OIDC Token、STS 临时密钥）。
- 网络隔离： 构建服务器不应直接访问生产环境网络。制品库应部署在独立的网络分段中。
- 审计日志： 所有组件必须开启审计日志，记录谁在什么时间、通过什么凭证、执行了什么操作。
- 不可变制品： 制品一旦发布到制品库，禁止覆盖或删除（除合规清理外）。版本号应唯一且不可变。
- 环境一致性： 部署到生产环境的制品，必须与经过测试环境的制品是同一个二进制文件（通过哈希校验）。