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

也许我的做法完全错误，但Azure Devops管道中似乎存在一个相当大的安全漏洞

我们的devops团队在历史上一直管理着我们的构建，一直到prem TFS和CI/CD。这样做是为了使我们的构建和发布标准化，跟踪环境和工具集升级，因为devops人员在这方面有更好的领域知识，并且通常使开发人员的生活更轻松。这都是好的做法

现在有了AzureDevOps和yaml管道，我们就有能力对我们的构建进行模板化（这是一件美妙的事情，微软应该赶上了）。但是，即使使用模板、“扩展”模板，以及阻止开发人员创建自己的管道的安全限制，it all的根文件（azure pipelines.yml）仍然存储在应用程序的源代码存储库中

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

在您说“好吧，在那里添加一些分支策略并强制代码审查/拉取请求”之前，这完全是愚蠢的，原因有二：

开发运营团队不必批准分支中的每一项更改，因为代码更改不是他们的领域。他们应该只需要批准azure-pipelines.yml文件，而不需要批准其他文件

这将需要在我们所有几十个回购协议上手动创建分支机构策略，更不用说这些回购协议中的每个分支机构了。开发人员还可以创建自己的分支，这完全规避了我们可能有的任何策略

是的，我们现在可能已经改变了历史，但这只会在事实发生后有所帮助。不是在构建环境被破坏之前

简言之，通过将管道定义插入到应用程序存储库中而不提供任何方式来智能地保护它们，Azure YAML管道允许开发人员自由支配devops的世界

---

我是不是遗漏了什么？人们是如何保护和管理yaml管道的？当然，对于拥有独立devops团队的组织来说，有一些策略需要保护他们的工作。我们如何保护/保护azure pipelines.yml？

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

虽然我个人反对责任之间如此严重的分歧。标准化是一回事，但它提供的保护是薄游标。最后，推动一项提高认识的计划要好得多

---

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

看起来您确实可以在项目范围内的*.yml文件上设置分支审批人策略，并使用通配符（项目设置->存储库->策略->分支策略）为所有未来分支设置分支审批人策略，因此这是一个巨大的进步。我将试一试，看看它是否能处理我的边缘情况。记住，PR构建将使用合并的结果来运行管道。您可以通过在环境级别设置检查来保护您的环境不接受此类生成。我在*分支上设置了一个项目范围的分支策略，为*.yml文件添加1个自动必需的“生成管理员”审阅者，这产生了一个不幸的副作用，即在所有代码基础上的每次提交都需要PRs。*.yml文件上的路径过滤器似乎没有按预期工作。回到实验…你找到解决方案了吗？这能回答你的问题吗？不完全是。。。其中提到了设置每个分支的策略，和/或设置文件路径验证，这只是答案的一半。我尝试设置一个项目范围的分支策略，类似于该链接中所述，但它强制管理员批准每个提交，即使只为yml文件设置了路径过滤器。因此，它引导我朝着一个方向前进，但这个方向没有正常工作。这一个是类似的，谈到了为子文件夹实施公关策略，但不是在项目范围内。我可以结合以下技术：