你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
注意
本文仅适用于 Microsoft Azure，不适用于任何其他 Microsoft 云产品/服务，例如 Microsoft 365 或 Microsoft Dynamics 365。
某些组织可能想要测试其 Azure 登陆区域平台部署的 Azure Policy 定义和分配、基于角色的访问控制（RBAC）自定义角色和分配等。 可以通过使用 Azure 资源管理器模板（ARM 模板）、Terraform、Bicep或通过 Azure 门户手动完成测试。 本指南提供了一种方法，可用于测试更改及其对 Azure 登陆区域平台部署的影响。
本文还可与平台自动化和 DevOps 关键设计领域指南一起使用，因为它与 PlatformOps 和 Central 职能团队和任务相关。 此外，还可以将其与采用策略驱动的防护措施中的指南相结合，了解如何对 Azure 登陆区域部署实施策略更改。
本指南最适用于管理生产管理组层次结构更改的可靠变更管理流程的组织。 在将部署部署到生产环境之前，可以独立使用 Canary 管理组层次结构来创作和测试部署。
注意
术语Canary用于避免与开发环境或测试环境混淆。 此名称仅用于说明目的。 你可以定义你认为适合 Canary Azure 登陆区域环境的任何名称。
同样，在整个指南中使用术语 生产环境/层次结构 来引用组织可能已具备的 Azure 登陆区域管理组层次结构，其中包含工作负荷的 Azure 订阅和资源。
平台定义
重要
本指南不适用于应用程序或服务所有者（称为登陆区域、工作负载、应用程序或服务）将使用的开发环境或测试环境。 这些在生产环境管 Azure 登陆区域理组层次结构和相关治理（RBAC 和 Azure Policy）中放置和处理。
有关应用程序工作负载和团队的开发、测试、用户验收测试（UAT）和生产环境的指导，请参阅 在 Azure 登陆区域中管理应用程序开发环境。
本指南仅适用于 Azure 登陆区域上下文中的平台级测试和更改。
Azure 登陆区域可帮助你设计和部署所需的 Azure 平台组件，使你能够大规模构造和作登陆区域。
本文涉及的平台资源和测试方法如下：
| 产品或服务 | 资源提供者和类型 |
|---|---|
| 管理组 | Microsoft.Management/managementGroups |
| 管理组订阅关联 | Microsoft.Management/managementGroups/subscriptions |
| 策略定义 | Microsoft.Authorization/policyDefinitions |
| 策略计划定义或策略集定义 | Microsoft.Authorization/policySetDefinitions |
| 策略分配 | Microsoft.Authorization/policyAssignments |
| RBAC 角色定义 | Microsoft.Authorization/roleDefinitions |
| RBAC 角色分配 | Microsoft.Authorization/roleAssignments |
| 订阅 | Microsoft.Subscription/aliases |
示例场景和结果
这个场景的一个示例是，一个组织想要测试一个新的 Azure Policy 的影响和结果，以便按照策略驱动的治理设计原则来管理所有登陆区域中的资源和设置。 他们不希望直接对生产环境进行更改，因为他们担心可能会产生影响。
使用 Canary 环境测试此平台更改将允许组织实施和审查 Azure Policy 更改的影响和结果。 此过程将确保在 Azure Policy 由组织实施到其生产环境之前满足组织的要求。
类似的方案可能是更改 Azure RBAC 角色分配和Microsoft Entra 组成员身份。 在生产环境中进行更改之前，可能需要进行某种形式的测试。
重要
这不是大多数客户的常见部署方法或模式。 Azure 登陆区域部署不是必需的。
图 1：Canary 管理组层次结构。
如图所示，整个 Azure 登陆区域生产管理组层次结构在 Tenant Root Group 下方重复。 Canary 名称追加到管理组显示名称和 ID。 ID 在单个 Microsoft Entra 租户中必须是唯一的。
注意
Canary 管理组显示名称可以与生产管理组显示名称相同。 这可能会给用户造成混淆。 因此，我们建议将名称“Canary”追加到显示名称及其 ID 中。
然后使用 Canary 管理组层次结构来简化以下资源类型的测试：
- 管理组
- 订阅位置
- RBAC
- 角色（内置和自定义）
- 任务
- Azure Policy
- 定义（内置和自定义）
- 计划（也称为集定义）
- 分配
如果不想部署 Canary 管理组层次结构，该怎么办？
如果不想部署金丝雀管理组层次结构，可以使用 沙盒订阅 测试在生产环境层次结构中的平台资源，如下图所示。
图 2：突出显示沙盒的 Azure 登陆区域管理组层次结构。
要在此场景中测试 Azure Policy 和 RBAC，需要一个 Azure 订阅，并将所有者 RBAC 角色分配给你希望用于完成测试的身份，例如用户帐户、服务主体或托管服务标识。 此配置仅允许你在沙盒订阅范围内创作、分配和修正 Azure Policy 定义和分配。
此沙盒方法还可用于订阅中的 RBAC 测试，例如，如果要开发新的自定义 RBAC 角色以授予特定用例的权限。 这些测试都可以在沙盒订阅中完成，并在层次结构中创建和分配较高级别角色之前进行测试。
此方法的优点是可以仅在需要时使用沙盒订阅，用完即可从环境中删除。
但是，此方法不允许使用从管理组层次结构继承的 RBAC 和 Azure 策略进行测试。
实施指南
以下是有关如何实施和使用 Canary 管理组层次结构以实现 Azure 登陆区域以及生产环境 Azure 登陆区域管理组层次结构的指南。
警告
如果目前通过门户来部署和管理 Azure 登陆区域环境，由于生产环境和 Canary 环境经常存在不同步的高风险，因此可能很难有效采用和使用 Canary 方法，从而无法提供类似于生产的复制层次结构和环境。
如果您符合这种情况，建议您考虑采用基础设施即代码（IaC）的方式在 Azure 登陆区域进行部署，如上所述。 或者请注意 Canary 版本与生产环境之间配置偏差的潜在风险，并谨慎行事。 有关详细信息，请参阅 使用 IaC 更新 Azure 登陆区域。
- 使用单独的 Microsoft Entra 服务主体 (SPN) 或托管服务标识 (MSI)，它们被授予对相关生产环境或 Canary 环境 Azure 登陆区域管理组层次结构的权限。
- 本指南遵循最小特权原则 (PoLP)
- 在 git 存储库、分支或存储库中使用单独的文件夹来保存用于生产环境和 Canary 环境 Azure 登陆区域部署的 IaC。
- 根据部署的层次结构，使用相关的 Microsoft Entra 服务主体 (SPN) 或托管标识 (MI) 作为 CI/CD 管道的一部分。
- 为 canary 环境实施与生产环境相同的 git 分支策略或安全措施。
- 考虑减少审批者的数量并检查 Canary 环境中有无快速失败的反馈。
- 使用相同的 Azure Pipelines 或 GitHub Actions（使用环境变量的）来更改正在部署的层次结构。 另一种选择是克隆管道并修改硬编码设置以定义正在部署的层次结构。
- 使用 Azure Pipelines DevOps 模板 或 GitHub Actions 工作流模板 可帮助你遵守 “不重复自己”（DRY） 原则。
- 在单独的计费帐户下拥有一组 Canary 订阅，例如企业协议 (EA) 帐户或 Microsoft 客户协议 (MCA) 发票部分，该部分可以根据需要在 Canary 管理组层次结构中移动。
- 最好始终将一组资源部署到 Canary 环境订阅中，以加快对 Canary 环境的更改的测试和验证。
- 有一组示例应用程序工作负荷体系结构，可以部署到 Canary 环境中的 Canary 订阅，以测试 Azure Policy 和 RBAC 的更改。 这有助于在部署更改并将更改提升到生产环境之前进行验证。
- 可以使用用于部署生产应用程序工作负荷的相同 IaC 模板部署这些示例工作负荷。 这有助于确保 Canary 环境与生产环境同步，并且要测试的更改有效且适用于生产环境。
- 应持续查看和更新示例工作负荷，以确保它们与组织中最新的体系结构和设计模式相关且最新。
- 如果向应用程序团队提供参考体系结构，请考虑将这些体系结构部署到 Canary 环境中。 这有助于根据参考体系结构验证更改，并确保这些更改适用于生产环境。
- 根据 Azure 登陆区域设计建议，将所有 Azure 订阅（包括任何 Canary 环境订阅）的所有 Azure 活动日志发送到生产环境 Azure Log Analytics 工作区。
- 这有助于安全和运营团队监视金丝雀环境，以发现由于在生产环境中测试 Azure Policy 和 RBAC 更改而可能导致的任何更改或问题。
提示
如果已在生产环境中部署了 Azure 登陆区域，现在想要添加 Canary 环境。 请考虑克隆当前生产环境层次结构的部署，并修改资源名称，以使用 Canary 命名方案为其添加前缀。
这是为了确保您正在部署的用于启用金丝雀环境的内容从一开始就与生产环境保持同步。 将 IaC 工具与 git 存储库一起使用时，可以轻松实现此目的。
使用单个 Microsoft Entra 租户
使用单个 Microsoft Entra 租户时要考虑的注意事项包括：
- 使用单个租户时，将遵循 Microsoft Entra 租户的 Azure 登陆区域设计建议。
- 在单个Microsoft Entra 租户中，可以将不同的Microsoft Entra 组用于生产环境和 Canary Azure 登陆区域环境，并将相同的用户分配到其相关的管理组层次结构。
- 由于不同 Microsoft Entra 租户中的多个标识，Microsoft Entra ID 许可成本增加或重复。 这与使用 Microsoft Entra ID P1 或 P2 功能的客户特别相关。
- 无论是在 Canary 环境还是在生产环境中，RBAC 更改都将更加复杂，因为这两个 Microsoft Entra 租户的用户和组可能并不相同。
- 假设用户和组 ID 在 Microsoft Entra 租户中不会相同，因为它们是全局唯一的。
- 减少由管理多个Microsoft Entra 租户造成的复杂性和管理开销。
- 例如，必须维护访问权限并登录到单独的租户以执行测试的特权用户可能会意外地更改生产环境而不是 Canary 环境。
- 降低了配置偏移和部署失败的可能性。
- 不需要创建额外的安全性和“应急破壁”或紧急访问过程。
- 减少实现 Azure 着陆区部署更改所需的摩擦和时间。
后续步骤
设置 Canary 环境后，可以开始测试 Azure Policy 和 RBAC 更改，然后再将其部署到生产 Azure 登陆区域管理组层次结构中。
在 Canary 环境中测试了对 Azure 策略的更改后，可以按照 采用策略驱动的防护措施 指南中所述的相同方法将其提升到生产环境。 这是通过使用 策略分配的强制模式功能完成的。 使用本指南中记录的方法，可以在生产环境中强制使用 Azure Policy 之前，继续执行额外的测试阶段，以达到预期的效果，从而帮助你对要进行的 Azure Policy 更改建立信心。
还可以查看应用程序团队用于开发和测试其工作负荷的沙盒环境。 这是 Canary 环境的单独概念，用于为应用程序团队在部署到生产环境之前开发和测试其工作负载提供安全环境。