你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
保护管道和 CI/CD 工作流
本文介绍如何保护 CI/CD 管道和工作流。
自动化和敏捷方法使团队实现更快交付，但同时给安全带来了复杂性，因为工作流扩展到了开发人员团队本身。
下图说明了 CI/CD 基线工作流。 红色配置图标 
表示必须由客户配置的安全权限。 这遵循共担责任模型，其中 Azure 和其他供应商提供权限，而这些权限必须由客户根据其治理模型和业务要求进行配置。
让我们查看该典型工作流的每个阶段，帮助你了解配置之间通常如何相互依赖。 工作流可能包含多个阶段。 以下概念将帮助你了解 CI/CD 并设计安全工作流。
阶段 1：Git 工作流
Git 中保存和管理代码变更（不仅涉及软件，还涉及“管道即代码”和基础结构即代码）。 Git 是一种分布式源代码管理软件。 将代码从本地计算机推送到集中式 Git 服务器时，可在接受代码之前应用业务规则。
拉取请求和协作
无论软件配置管理 (SCM) 服务型软件 (SaaS) 供应商是谁，行业标准工作流都会使用拉取请求，此请求会在源代码接受之前充当自动化质量守护程序和手动审批步骤。
拉取请求工作流旨在引入良性摩擦，因此应仅应用于保护特定 Git 分支。 尤其适用于将触发自动化工作流的分支，这些工作流会部署、配置或以任何其他方式影响云资源。 这些分支称为受保护分支，通常遵循命名约定，如 production 或 releases/*。
拉取请求通常需要：
- 同级评审
- 传递持续集成 (CI) 生成
- 手动审批
如果满足要求，则接受并合并代码变更。
限制访问受保护分支
拉取请求工作流与受限访问控制一起使用。 但是，除非将服务器配置为拒绝对受保护分支的直接更改，否则不能强制执行拉取请求工作流。
开发人员不能直接推送到 production 分支，而是必须创建针对受保护分支的拉取请求。 每个 SCM 供应商都有不同方式来实现对受保护分支的受限访问。 例如，使用 GitHub 时，此功能仅适用于使用 GitHub 团队或 GitHub Enterprise 云的组织。
记录 Git 访问模型
由于协作模型很复杂，包含许多移动部分，因此，创建一个表来记录代码变更触发部署的所有可能方式会很有帮助，例如：
| 分支名称 | 是否需要 PR？ | 是否部署？ | 开发人员访问权限 | 管理员访问权限 |
|---|---|---|---|---|
feat/* |
否 | 否 | 读/写 | 读/写 |
main |
是 | 过渡 | 读取 | 读取/写入 |
production |
是，仅从 main |
生产 | 读取 | 读取/写入 |
此 Git 访问表示例过度简化，只为说明其用途。 在实践中，通常会有更多参与者、更多部署目标以及针对不同用例运行的多个管道。 根据组织和工作负载的要求，表结构可能会有所不同。
该表应有助于解答以下问题：
- 如果开发人员将代码变更推送到分支 X，它会部署吗？ 如果是，部署到哪个环境？
- 在应用程序代码生命周期的哪个阶段执行漏洞扫描？
- 如果发现安全漏洞，需要进行多少次代码推送和审批才能投入生产环境？
此表不仅对调试和静态文档有用，还对团队协作有帮助。 开发人员能够清楚地了解到，工作流中已引入良性摩擦，从而将代码质量和安全性放在首位。 更重要的是，它向开发人员展示了将代码变更投入生产环境的预期路径。
DevOps 是一趟旅程，因此 Git 访问模型并非静态。 当团队找到自己的节奏并渐渐融入时，这趟旅程也随之改变和逐渐完善。 因此务必将此文档尽可能存储在靠近代码的位置，例如 Git 存储库中。
若要详细了解拉取请求和受保护分支，请参阅：
阶段 2：管道即代码
管道即代码移动将管道定义和配置从 CI 供应商移动到开发人员，使生成和部署逻辑更接近相应的应用逻辑，加速了自动化的采用和部署。 此处更大的灵活性也意味着更大的责任。
在 UI 驱动的管道中采取 RBAC 控制可以防止个人用户进行破坏性的更改。 但是管道即代码通常使用特权标识运行，可能会破坏你的工作负载（如果收到指示这么做）。
阶段 3：保护部署凭据
管道和代码存储库不应包含硬编码凭据和机密。 凭据和机密应存储在其他位置，并使用 CI 供应商功能确保其安全性。 由于管道作为无外设代理运行，因此不应使用个人密码。 应改用无外设安全主体（如服务主体或托管标识）运行管道。 还应在 CI 平台中安全管理对此安全主体凭据、数据库连接字符串和第三方 API 密钥的访问。
凭据的保护方式、入口和审批是特定于供应商的功能。 选择 CI 平台时，请确保它支持所需的所有功能。
Azure Pipelines 是一项企业级持续集成解决方案，其中凭据存储为服务连接，在此基础上可以配置审批和检查。 此配置包括手动审批和特定分支或管道授权。
Azure Key Vault
如果 CI 平台支持它，请考虑将凭据存储在专用密钥存储中，例如 Azure Key Vault。 凭据由生成代理在运行时提取，可减少攻击面。
阶段 4：保护 Azure 资源
应根据最小特权原则（同时应用于权限和作用域）保护 Azure 资源。
有关详细信息，请参阅：
为生成代理创建自定义角色
CI/CD 自动化不仅适用于应用程序，还适用于基础结构。 基础结构即代码 (IaC) 模板可确保部署一致，并帮助集中式云平台团队扩大规模。
务必了解 IaC 自动化可能会出错。 它可能出现配置错误，在最糟糕的情况下，可能永久删除基础结构。 规划云旅程时，预先确定哪些是需要人工干预的业务关键操作。
例如，可以将无法删除管理锁应用于数据等业务关键资源。 若要防止发生这种情况，可以从 CI 自动化中使用的服务主体中删除Microsoft.Authorization/*/Delete权限。 在此示例和用例中，服务主体可以创建管理锁，但不能删除它。
建议为 CI 代理创建自定义角色。 请记住，生成代理以无外设方式运行，无外设代理是没有控制指令的。 请慎重选择权限。
若要了解更多信息，请参阅以下文章：
资源
后续步骤
现在，你已了解如何保护 DevOps，接下来请详细了解从 DevOps 到 Azure 的端到端治理。