如何限制Azure Pipeline YML被功能分支提交触发并防范恶意YML提交

下面是几个实用的解决办法，能从根源或流程上阻止这种情况：

• 限制YML文件的修改权限
  在Azure DevOps仓库的分支策略里，给所有分支（包括功能分支）设置文件路径权限限制：只允许项目维护者或管理员修改.azure-pipelines目录下的YML文件，甚至是仓库里所有*.yml文件。普通开发者提交的自定义YML修改会直接被拦截，必须经过指定人员审批才能合并，从源头杜绝自定义YML被提交的可能。

• 关闭自动管道检测，改用手动配置
  默认Azure DevOps会自动扫描仓库里的YML文件并创建管道，这是自定义YML能被触发的核心原因。你可以去项目设置的「管道」->「设置」里，关掉「允许仓库中的YAML管道」选项，然后手动创建唯一的管道，关联你指定的main分支YML文件。这样一来，只有你手动配置的管道会运行，开发者提交的任何自定义YML都不会被系统识别并触发。

• 加固管道的触发与运行条件
  就算开发者侥幸提交了自定义YML，也可以通过管道本身的条件限制让它无法执行：

  • 首先在触发规则里明确只监听main分支的指定YML文件：

    trigger:
      branches:
        include:
          - main
      paths:
        include:
          - /your/official-pipeline.yml
        exclude:
          - '*'
    

  • 再在作业层面增加双重校验，确保只有官方管道在main分支上才会运行：

    jobs:
      - job: Build
        condition: |
          and(
            eq(variables['Build.SourceBranch'], 'refs/heads/main'),
            eq(variables['Build.DefinitionName'], '你的官方管道名称')
          )
        steps:
          # 你的作业步骤
    

• 用环境权限拦截非法部署
  如果你的管道涉及部署到重要环境，可以给目标环境设置权限，只允许你配置的官方管道访问。就算自定义YML被触发，也会因为没有环境权限而无法完成后续操作，避免造成实际影响。

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