什么是 Azure 服务组？

Azure 服务组提供了一种灵活的方式来跨订阅和资源组组织和管理资源，与任何现有的 Azure 资源层次结构并行。 它们非常适合需要跨边界分组、最小权限和跨资源数据聚合的方案。 这些功能使团队能够创建与运营、组织或基于角色的需求相符的定制资源集合。 本文有助于概述什么是服务组、使用这些组的方案以及重要事实。

关键功能

• 多个层次结构：服务组支持将资源分组到不同视图中以实现多个目的的方案。
• 灵活成员身份：服务组允许来自不同订阅的资源组合在一起，从而提供统一的视图和管理功能。 它们还允许对订阅、资源组和资源进行分组。 同一资源可以连接到许多不同的服务组，允许创建和使用不同的客户角色和方案。
• 低特权管理：服务组旨在以最少的权限运行，确保用户可以管理资源，而无需过多的访问权限。

示例方案

客户可以创建许多不同的视图，以支持其组织资源的方式。

• 资源的统一视图

  • 具有多个应用程序和环境的组织可以使用服务组跨不同环境创建资源信息的集中视图。 来自不同管理组或订阅中的各种环境的成员资源或资源容器可以链接到单个服务组，为资源详细信息提供统一的参考点。
  • 由于服务组不会从其成员继承权限，因此客户可以应用最低特权原则来为允许查看资源信息的服务组分配权限。 此功能允许两个用户访问同一服务组，但只允许一个用户查看某些资源的情况。

• 创建清单

  • 客户可以将资源连接到服务组，以获取整个环境中特定类型或功能的所有资源的合并视图。

• 不同角色
  • 借助服务组，组织能够针对不同角色及其自己的单个视图在同一资源上管理多个层次结构。 客户可以使用同样的资源成为工作负荷服务组、部门服务组以及包含所有生产资源的服务组的成员。

工作原理

Azure 服务组是允许对资源进行分组的并行租户级别层次结构。 与管理组、订阅和资源组的分离允许服务组多次连接到不同的资源和资源容器，而不会影响现有结构。

有关服务组的信息

• 服务组在 Microsoft.Management 资源提供程序中创建。
• 服务组允许自嵌套创建最多 10 个“级别”的分组深度。 嵌套可以通过服务组资源中的“父”属性进行管理。
• 服务组上的角色分配只能继承到 子服务组。 没有通过资源或资源容器的成员身份的继承。
• 来自同一订阅的服务组成员限制为 2000 个。 这意味着，在一个订阅、资源或资源组中，服务组的成员身份总数不能超过 2,000 个。
• 在预览窗口中，单个租户中的服务组限制为 10,000 个。
• 服务组和服务组成员 ID 最多支持 250 个字符。 它们可以是字母数字字符和特殊字符：- _ （ ）。 ~
• 服务组需要全局唯一 ID。 两个 Microsoft Entra 租户不能具有 ID 相同的服务组。
• 服务组的成员身份由针对所需成员（资源、资源组或订阅）的“Microsoft.Relationship/ServiceGroupMember”进行管理，同时以所需服务组为目标。

Azure 资源管理器分组

Azure 提供了各种各样的资源容器，使我们的客户能够在许多不同的规模上管理资源。 服务组只是用于组织环境的 Azure 资源管理器（ARM）容器系列中的最新服务组。

下表汇总了组之间的差异。

场景比较

*：将策略应用于某个范围时，强制措施将应用于范围中的所有成员。 例如，在资源组上，它仅适用于其下的资源。

**：标记可以跨范围应用，并单独添加到资源。 Azure Policy 具有有助于管理标记的内置策略。

：Azure 标记可用作 Azure Policy 中的条件，以将策略应用于某些资源。 Azure 标签有一定的限制。

有关服务组的重要事实

• 单个租户可以支持 10,000 个服务组。
• 服务组树最多可以支持 10 个深度级别。 此限制不包括根级别。
• 每个服务组可以有多个子项。
• 单个服务组名称/ID 最多可以包含 250 个字符。
• 服务组成员的数量没有限制，但一个订阅内的关系（包括 ServiceGroupMember）的数量限制为 2,000 个

根服务组

服务组（类似于管理组）拥有一个根服务组，它是该租户内所有服务组的最上级。 根服务组的 ID 与其租户 ID 相同。

服务组在租户中收到的第一个请求上创建根服务组，用户无法创建或更新根服务组。 "/providers/microsoft.management/servicegroups/[tenantId]"

必须由在租户级别具有“microsoft.authorization/roleassignments/write”权限的用户授予对根的访问权限。 例如，租户的全局管理员可以提升其对租户的访问权限，以拥有这些权限。 有关提升租户全局管理员访问权限的详细信息

基于角色的访问控制

在预览版中，有三个用于支持服务组的内置角色定义。

• 服务组管理员：此内置角色管理服务组和关系的各个方面，是创建服务组时向用户 提供的默认角色 。

• 服务组参与者：当用户需要创建或管理服务组的生命周期时，应向用户提供此内置角色。 此角色允许除角色分配功能之外的所有操作。

• 服务组读取者：此内置角色提供对服务组信息的只读访问权限，并且可以分配给其他资源以查看连接关系。

租户中具有有效权限的任何人都可以在根目录下创建服务组。 创建服务组的用户将成为“服务组管理员”。 若要编辑服务组或创建子服务组，用户必须在该服务组中具有“服务组参与者”权限。 若要添加成员，用户必须在服务组中具有“服务组参与者”角色，并在资源上具有“Microsoft.Relationship/write”权限。

相关内容

• 快速入门：使用 REST API 创建服务组
• 如何：管理服务组
• 使用 REST API 连接服务组成员