如何在GitHub中管控工作流部署，确保仅批准的代码/基础设施上线？

背景 #

之前在Azure DevOps中，我们通过流水线模板限制只有Azure团队能修改生产发布步骤，以此管控Azure部署内容。现在切换到GitHub后，不清楚如何在管控/策略层面实现同等效果，需要向审计方证明只有经批准的代码/基础设施会被部署。

我的初步思路 #

• 在GitHub仓库中创建名为prd的Environment
• 由Azure团队负责prd Environment的审批
• 但不确定如何验证待审批的流水线没有部署非标准内容
• 考虑过使用标准YAML模板，但即便调用模板，似乎也无法阻止贡献者在YAML文件中添加额外的基础设施部署步骤，对吗？

核心疑问 #

我们能否确保不会通过贡献者新增的步骤部署非预期的资源？

GitHub Environment仅能通过审批保护Azure连接密钥，无法对使用该连接的流水线代码提供管控机制，界面如下：

解决方案思路 #

1. 强制使用受管控的部署模板，杜绝自定义步骤 #

• 将生产部署的核心逻辑封装到私有模板仓库中，仅开放修改权限给Azure团队
• 在主仓库的分支保护规则中设置：
  • 禁止直接修改主分支的工作流文件，所有变更必须通过PR合并
  • PR必须经过Azure团队审核，确保工作流仅调用受管控的模板，未新增自定义部署步骤
• 启用GitHub仓库的Restrict which actions can be run in workflows设置，仅允许使用受信任的官方动作和私有模板，禁止第三方或自定义动作执行部署操作

2. IaC代码的合规管控 #

• 用Terraform/ARM模板等IaC工具管理Azure资源，将IaC代码存放在单独的受管控仓库，仅Azure团队可修改
• 在主仓库的PR流程中添加校验步骤：检查部署工作流是否仅引用受管控IaC仓库中的模板，未嵌入自定义资源定义
• 引入checkov或trivy等工具做IaC合规扫描，确保待部署资源符合安全规范，扫描通过作为PR合并的前置条件

3. 部署前的内容验证 #

• 在生产部署的审批环节，除人工审批外添加自动化校验：
  • 拉取待部署的代码与IaC模板，和已批准的基线版本对比，确认无未授权变更
  • 生成部署变更报告，列出所有待创建/修改/删除的资源，作为审批依据，审批人需确认报告内容符合预期

4. 权限与凭据强化管控 #

• 限制Azure部署权限到专用服务主体，该主体仅能部署指定类型的资源，且仅可访问指定资源组
• 将服务主体凭据存储在GitHub Secrets中，仅Azure团队可管理这些Secrets；同时通过Environment权限设置，仅指定工作流可访问这些Secrets

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