如何保护Azure Devops中的azure-pipelines.yml管道文件

Question

也许我完全以错误的方式来处理此问题，但是Azure Devops Pipelines中似乎存在相当大的安全漏洞。

我们的devop团队在过去一直管理着我们的构建，一直到本地TFS以及我们到CI / CD的旅程。这样做是为了使我们可以标准化我们的构建和发布，跟踪环境和工具集升级，因为devop的人们在该领域具有更好的领域知识，并且通常使开发人员的生活更轻松。这都是好习惯。

现在，有了Azure Devops和yaml管道，我们就可以对构建进行模板化（这是一件很了不起的事情，大约是在Microsoft赶上这一步的时候）。但是，即使有了模板，“扩展”模板以及安全性限制（阻止开发人员创建自己的管道），所有这些文件的根文件（azure-pipelines.yml）仍存储在应用程序的源代码存储库中。

因此，不允许开发人员创建新管道，但他们可以编辑他们想要的azure-pipelines.yml文件，这意味着擦除我们的devops团队编写的模板/扩展代码，并可能注入恶意或其他方式非托管的更改。甚至完全删除文件并破坏管道。这是椰子。

在您说“好吧，在那儿拍打一些分支策略并强制执行代码审查/请求”之前，这完全是愚蠢的，其原因有两个：

1. 开发人员团队不必批准分支中的每个更改，因为代码更改不是他们的职责范围。他们只需要批准azure-pipelines.yml文件，其余的就不用了。
2. 这将需要在我们所有数十个存储库上手动创建的分支策略，更不用说那些存储库中的每个分支。开发人员还可以创建自己的分支机构，从而完全规避我们可能拥有的任何政策。

是的，我们现在可能已有变更历史记录，但这只有在事实发生后才有所帮助。并非在构建环境被破坏之前。

简而言之，通过将管道定义插入应用程序存储库中并且不提供任何智能保护它们的方法，Azure YAML管道允许开发人员自由支配以在devop的世界中造成破坏。

我在这里想念什么吗？人们如何保持对Yaml管道的保护和管理？对于拥有独立的开发团队需要保护其工作的组织，肯定有一些策略。我们如何保护/保护azure-pipelines.yml？

Answer 1

您可以在重要分支上强制执行拉取请求，并在更改管道时要求审阅者。这样的分支策略可以使用带有通配符的分支策略在整个团队项目中强制执行

https://jessehouwing.net/azure-repos-git-configuring-standard-policies-on-repositories/

尽管我个人反对这种强烈的责任分工。标准化是一回事，但是它所提供的保护却很少。最后，最好开展一个意识计划。

（可选）保护目标环境以需要管道模板，并确保该模板将自身注入目标管道，而不是选择加入模板的管道。在Azure Pipeline Environments中，您可以设置策略以要求使用特定模板。