GitLab CI/CD生产环境部署权限安全管控方案咨询

针对你遇到的维护者可篡改.gitlab-ci.yml导致权限控制失效的问题，企业里通常会从GitLab后台权限配置而非流水线文件层面入手，结合以下几种方案实现生产环境的严格管控：

1. 启用「受保护环境（Protected Environments）」（核心方案） #

GitLab的environment并非只是标记，其配套的受保护环境功能是管控生产部署权限的核心：

• 在项目「设置」→「CI/CD」→「受保护环境」中，添加生产环境（比如production）；
• 配置「部署权限」为仅GitLab管理员，同时可设置「审批权限」也限定为管理员；
• 在.gitlab-ci.yml中，将生产部署job绑定到该环境：

  deploy_prod:
    stage: deploy
    environment: production
    script:
      - # 生产部署脚本
    only:
      - prod # 仅受保护分支触发
  

• 效果：只有拥有部署权限的管理员才能触发/审批该环境的部署任务，普通维护者即便修改.gitlab-ci.yml，也无法绕过后台的权限校验，无权限用户触发的任务会直接失败，完全符合你想要的「类似保护Runner」的机制。
• 关键：受保护环境的配置权限默认仅开放给项目「所有者（Owner）」或GitLab管理员，项目维护者（Maintainer）无法修改该配置，从根源避免权限被篡改。

2. 隔离生产部署流水线到独立项目 #

将生产部署的逻辑完全剥离出业务项目，单独创建一个仅GitLab管理员有权限访问的生产部署项目：

• 业务项目的流水线仅负责构建、测试，如需触发生产部署，只能通过GitLab的「跨项目流水线触发」功能调用生产项目的流水线；
• 生产项目的流水线配置、敏感变量、Runner权限均由管理员管控，业务项目的维护者无法触及任何生产部署相关的配置；
• 额外可设置生产项目的流水线仅接受管理员手动触发，或需管理员审批后才能执行。

3. 结合「受保护分支」+「受保护变量」双重锁 #

• 把生产部署对应的分支（比如prod）设置为受保护分支，仅允许GitLab管理员推送/合并代码，同时关闭维护者的分支操作权限；
• 将生产部署所需的敏感变量（如服务器密钥、部署令牌）设置为受保护变量，仅受保护分支的流水线才能访问；
• 这样维护者既无法修改生产分支的代码触发部署，也无法获取生产部署的敏感信息，即便篡改.gitlab-ci.yml也无法执行有效部署。

4. 强制手动审批+权限限定 #

在生产部署job中配置手动触发，并结合受保护环境的审批权限：

deploy_prod:
  stage: deploy
  environment: production
  when: manual
  script:
    - # 生产部署脚本
  only:
    - prod

• 只有GitLab管理员能看到并审批该手动任务，维护者即便触发了流水线，也无法推进生产部署环节；
• 该配置结合受保护环境的权限后，审批权完全由管理员掌控，不受.gitlab-ci.yml修改影响。

内容的提问来源于stack exchange，提问作者Ridwan