1. 权限边界评审概述
什么是 GitLab CI 模板目录权限边界评审
权限边界评审（Permission Boundary Review）是针对 GitLab CI 模板目录中所有文件、目录、变量、作业（Job）和环境（Environment）所设置的访问控制与执行权限进行系统性审查的过程。其核心是识别并确认：谁可以读取、谁可以修改、谁可以触发执行模板目录中的 CI 配置。
在 GitLab CI 中，模板目录通常包含 .gitlab-ci.yml、templates/、includes/ 等关键路径。这些目录中的 YAML 文件定义了流水线的作业逻辑、变量注入、环境部署策略以及安全扫描步骤。权限边界评审即是对这些路径的 可见性（Visibility）、可写性（Writability） 和 可执行性（Executability） 进行逐层审计。
关键定义：权限边界 = 项目可见性（Public/Internal/Private）+ 角色权限（Guest/Reporter/Developer/Maintainer/Owner）+ CI 作业触发条件（分支/标签/合并请求/调度）+ 环境保护规则（Protected Environment）。
为什么需要做这个评审
在持续集成/持续部署（CI/CD）流水线中，模板目录是 配置即代码（Configuration as Code） 的核心载体。一旦模板目录的权限边界出现漏洞，攻击者或内部非授权人员可能通过以下方式造成破坏：
- 模板篡改： 修改
templates/deploy.yml中的部署脚本，注入恶意命令，导致生产环境被植入后门。 - 变量泄露： 在
variables/目录中暴露数据库密码、API 等敏感信息，被低权限用户读取。 - 作业劫持： 非授权人员通过合并请求触发本应受保护的部署作业，绕过审批流程直接上线。
- 环境逃逸： 开发环境模板被用于生产环境部署，导致配置漂移和安全基线失效。
| 风险类型 | 典型场景 | 潜在影响 |
|---|---|---|
| 模板篡改 | Developer 角色直接修改 templates/security-scan.yml |
安全扫描被绕过，漏洞未检出即上线 |
| 变量泄露 | CI 变量未设置 protected 和 masked 属性 |
敏感凭据在作业日志中明文暴露 |
| 作业劫持 | 非受保护分支触发 deploy-to-production 作业 |
未经审批的代码直接部署到生产环境 |
| 环境逃逸 | 模板中 environment: production 未绑定受保护环境 |
任意分支均可覆盖生产环境资源 |
⚠️ 常见误区： 很多团队认为“项目设为 Private 就安全了”。实际上，Private 项目中的 CI 模板目录仍然可能被 Maintainer 以下角色通过合并请求间接修改，或者通过 CI 调度（Pipeline Schedule）被外部触发。权限边界评审必须覆盖所有执行路径。
评审的核心目标与价值
权限边界评审不是一次性的安全审计，而是 持续的安全左移实践。其核心目标可以归纳为以下四个维度：
- 最小权限原则（Principle of Least Privilege）： 确保每个角色、每个作业、每个环境只拥有完成其任务所必需的最小权限集合。
- 职责分离（Separation of Duties）： 模板编写者、流水线触发者、部署执行者、审批者之间形成明确的权限隔离，避免单人拥有完整攻击链。
- 可审计性（Auditability）： 所有权限变更、模板修改、作业触发都有日志记录，能够追溯到具体操作者和时间点。
- 自动化验证（Automated Validation）： 将权限边界规则编码为自动化检查项，在每次合并请求和流水线执行时自动校验。
💡 最佳实践： 建议将权限边界评审纳入每个迭代的 DoD（Definition of Done）中。在创建新的 CI 模板或修改现有模板时，同步更新权限边界文档，并在合并请求模板中增加“权限影响自检清单”字段。