保护 Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines 带来了独特的安全挑战。 可以使用管道运行脚本或将代码部署到生产环境。 但你想要确保 CI/CD 管道不会成为运行恶意代码的途径。 你还希望确保仅部署要部署的代码。 在提高安全性的同时,还要使团队拥有运行自己的管道所需的灵活性和能力,必须在这二者之间进行权衡。

注意

Azure Pipelines 是 Azure DevOps Services 集合中的成员之一,所有这些服务都构建在 Azure 中的同一安全基础结构之上。 若要了解有关所有 Azure DevOps Services 的安全性的主要概念,请参阅 Azure DevOps 数据保护概述Azure DevOps 安全和标识

传统上,组织通过严厉的锁定实现了安全性。 代码、管道和生产环境对访问和使用有严格的限制。 在只有少数用户和项目的小型组织中,这种“立场”相对容易管理。 但在大型组织中,情况并非如此。 如果许多用户都拥有对代码的“参与者”访问权限,则必须“假定存在违规”。 “假定存在违规”意味着用户的行为就像攻击者拥有部分(如果不是全部的话)存储库的“参与者”访问权限一样。

在这种情况下,目标是防止攻击者在管道中运行恶意代码。 恶意代码可能会窃取机密或破坏生产环境。 另一个目标是防止攻击者从受攻击的管道横向接触其他项目、管道和存储库。

YAML 管道为 Azure Pipelines 提供最佳安全性。 与经典生成和发布管道相比,YAML 管道具有以下特点:

  • 可以进行代码评审。 YAML 管道与任何其他代码段没有什么不同。 可以通过强制使用拉取请求来合并更改,防止恶意行动者在管道中引入恶意步骤。 分支策略让你可以轻松地进行设置。
  • 提供资源访问管理。 资源所有者决定 YAML 管道是否可以访问资源。 此安全功能控制诸如窃取另一个存储库之类的攻击。 审批和检查为每个管道运行提供访问控制。
  • 支持运行时参数。 运行时参数有助于避免与变量相关的大量安全问题,例如参数注入

本系列文章概述了一些建议,可帮助你构建安全的基于 YAML 的 CI/CD 管道。 此外还介绍了可以在安全性和灵活性之间进行权衡的地方。 本系列还假设你熟悉 Azure Pipelines、核心 Azure DevOps 安全构造Git

涵盖的主题: