通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 登陆区域的测试方法

  • 项目

注意

本文仅适用于 Microsoft Azure，不适用于任何其他 Microsoft 云产品/服务，例如 Microsoft 365 或 Microsoft Dynamics 365。

某些组织可能想要针对 Azure Policy 定义和分配、基于角色的访问控制（RBAC）自定义角色和分配等测试其 Azure 登陆区域平台部署。 可以通过使用 Azure 资源管理器 模板（ARM 模板）、AzOps、Terraform、Bicep 或通过Azure 门户手动完成测试。 本指南提供了一种方法，可用于测试 Azure 登陆区域平台部署中的更改及其影响。

本文还可与平台自动化和 DevOps 关键设计领域指南一起使用，因为它与 PlatformOps 和 Central 职能团队和任务相关。

本指南最适用于具有对生产环境管理组层次结构的更改进行控制的强大变更管理流程的组织。 在将部署部署到生产环境之前，可以独立使用 Canary 管理组层次结构来创作和测试部署。

注意

术语 Canary 用于避免与开发环境或测试环境混淆。 此名称仅用于说明目的。 可以定义你认为适合 Canary Azure 登陆区域环境的任何名称。

同样，在本指南中使用术语“生产环境”来指代组织可能拥有的管理组层次结构，其中包含适用于工作负载的 Azure 订阅和资源。

平台定义

重要

本指南不适用于应用程序或服务所有者（称为登陆区域、工作负载、应用程序或服务）将使用的开发环境或测试环境。 这些在生产环境管理组层次结构和相关治理（RBAC 和 Azure Policy）中放置和处理。

本指南仅适用于 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 登陆区域部署不是必需的。

Diagram of the management group hierarchy with the canary environment testing approach.

图 1：Canary 管理组层次结构。

如图所示，整个 Azure 登陆区域生产环境管理组层次结构在下方 Tenant Root Group重复。 Canary 名称追加到管理组显示名称和 ID。 ID 在单个 Microsoft Entra 租户中必须是唯一的。

注意

Canary 环境管理组显示名称可以与生产环境管理组显示名称相同。 这可能会给用户造成混淆。 因此，我们建议将名称“Canary”追加到显示名称及其 ID 中。

然后使用 Canary 环境管理组层次结构来简化以下资源类型的测试：

  • 管理组
    • 订阅位置
  • Rbac
    • 角色（内置和自定义）
    • 分配
  • Azure Policy
    • 定义（内置和自定义）
    • 计划（也称为集定义）
    • 分配

如果不想部署整个 Canary 环境管理组层次结构，该怎么办？

如果不想部署整个 Canary 环境管理组层次结构，可以使用沙盒订阅测试生产环境层次结构中的平台资源，如下图所示。

Diagram of the testing approach that uses sandboxes.

图 2：突出显示沙盒的企业级管理组层次结构。

要在此场景中测试 Azure Policy 和 RBAC，需要一个 Azure 订阅，并将所有者 RBAC 角色分配给你希望用于完成测试的身份，例如用户帐户、服务主体或托管服务标识。 此配置仅允许你在沙盒订阅范围内创作、分配和修正 Azure Policy 定义和分配。

此沙盒方法还可用于订阅中的 RBAC 测试，例如，如果要开发新的自定义 RBAC 角色以授予特定用例的权限。 这些测试都可以在沙盒订阅中完成，并在层次结构中创建和分配较高级别角色之前进行测试。

此方法的优点是可以仅在需要时使用沙盒订阅，用完即可从环境中删除。

但是，此方法不允许使用从管理组层次结构继承的 RBAC 和 Azure 策略进行测试。

使用单个 Microsoft Entra 租户

使用单个 Microsoft Entra 租户时要考虑的注意事项包括：

  • 遵循 Microsoft Entra 租户的企业规模设计建议。
  • 根据 云采用框架 Azure 最佳做法，在单个目录和标识指南上标准化，大多数情况下，单个 Microsoft Entra 租户都是最佳做法。
    • 在单个 Microsoft Entra 租户中，可以将不同的 Microsoft Entra 组用于生产环境和 Canary Azure 登陆区域环境，这些环境与同一用户在同一 Microsoft Entra 租户中分配给其相关管理组层次结构。
  • 由于不同 Microsoft Entra 租户中的多个标识，增加了或重复了 Microsoft Entra ID 许可成本。
    • 这一点与使用 Microsoft Entra ID P1 或 P2 功能的客户尤其相关。
  • 在 Canary 环境和生产环境中，RBAC 更改将更加复杂，因为两个 Microsoft Entra 租户中的用户和组可能不完全相同。
    • 此外，用户和组 ID 在 Microsoft Entra 租户中不会相同，因为它们是全局唯一的。
  • 减少由管理多个 Microsoft Entra 租户造成的复杂性和管理开销。
    • 必须保持访问权限并登录到单独的租户才能执行测试的特权用户可能会意外更改生产环境，而不是更改 Canary 环境，反之亦然。
  • 降低了配置偏移和部署失败的可能性。
  • 不需要创建额外的安全性和“应急破壁”或紧急访问过程。
  • 减少对 Azure 登陆区域部署的更改所需的摩擦和时间。

实施指南

下面是有关如何实现和使用 Canary 管理组层次结构以及生产环境管理组层次结构的指南。

警告

如果目前使用门户部署和管理 Azure 登陆区域环境，则可能很难有效地采用和使用 Canary 方法，因为生产环境和 Canary 环境经常失控，因此不会提供类似于副本 (replica)的生产层次结构和环境。

如果在此方案中，请考虑迁移到 Azure 登陆区域的基础结构即代码部署方法（如上所述）。 或者请注意 Canary 与生产之间配置偏差的潜在风险，并继续小心。

  1. 使用针对相关生产环境或 Canary 环境管理组层次结构授予权限的单独 Microsoft Entra 服务主体（SPN）或托管服务标识（MSIs）。
    • 本指南遵循最小特权原则 (PoLP)
  2. 使用 git 存储库、分支或存储库中的单独文件夹来保存生产环境和 Canary 环境 Azure 登陆区域部署的基础结构即代码。
    • 根据要部署的层次结构，使用相关的 Microsoft Entra 服务主体（SPN）或托管服务标识（MSIs）作为 CI/CD 管道的一部分。
  3. 为 Canary 环境实施 git 分支策略或安全性，就像为生产环境实施的那样。
    • 考虑减少审批者的数量并检查 Canary 环境中有无快速失败的反馈。
  4. 使用相同的 Azure Pipelines 或 GitHub Actions（使用环境变量的）来更改正在部署的层次结构。 另一种选择是克隆管道并修改硬编码设置以定义正在部署的层次结构。
  5. 在单独的 EA 部门和帐户下拥有一组 Canary 订阅，可以根据需要在 Canary 管理组层次结构中移动。
    • 将一组资源始终部署到 Canary 环境订阅中可能会有所帮助。
    • 拥有基础结构即代码模板（例如 ARM 模板、Bicep 或 Terraform）可能会有所帮助，这些模板可以创建一组资源来验证 Canary 环境中的更改。
  6. 根据 Azure 登陆区域设计建议，将所有 Azure 订阅（包括任何 Canary 环境订阅）的所有 Azure 活动日志发送到生产环境 Azure Log Analytics 工作区。

提示

如果已在生产环境中部署了 Azure 登陆区域，现在想要添加 Canary 环境。 请考虑克隆生产环境层次结构的当前部署，并修改资源名称，以使用 Canary 命名方案为其添加前缀。

这是为了确保要部署的内容，以便从一开始就与生产环境保持同步。 将基础结构即代码工具与 git 存储库一起使用时，可以轻松实现此目的。

后续步骤

了解如何实现登陆区域沙盒环境。

实现登陆区域沙盒环境