Partager via

Azure Lighthouse 方案中的租户、用户和角色

在将客户加入 Azure Lighthouse 之前，请务必了解 Microsoft Entra 租户、用户和角色的工作原理以及如何在 Azure Lighthouse 方案中使用它们。

租户是 Microsoft Entra ID 的专用受信任的实例。 通常，每个租户表示一个组织。 Azure Lighthouse 支持将资源从一个租户逻辑投影到另一个租户。 这样一来，管理租户中的用户（例如属于服务提供商的用户）可以访问客户租户中的委派资源，或者让具有多个租户的企业集中其管理操作。

为了实现此逻辑投影，必须将客户租户中的订阅（或订阅中的一个或多个资源组）加入 Azure Lighthouse。 可以通过 Azure 资源管理器模板或将公共或私有产品/服务发布到 Azure 市场来完成此加入过程。

无论使用哪种加入方法，都需要定义授权。 每个授权都包含一个 principalId 和一个内置角色，前者表示管理租户中的 Microsoft Entra 用户、组或服务主体，后者定义将授予委派资源的特定权限。

备注

除非显式指定，否则 Azure Lighthouse 文档中对“用户”的提及可能会适用于授权中的 Microsoft Entra 用户、组或服务主体。

定义用户和角色的最佳做法

创建授权时，建议使用以下最佳做法：

  • 在大多数情况下，需要将权限分配给 Microsoft Entra 用户组或服务主体，而不是分配给一系列单独的用户帐户。 这样做可通过租户的 Microsoft Entra ID 添加或移除单个用户的访问权限，而不必在每次个人访问要求发生更改时更新委派。
  • 遵循最小特权原则。 为了减少无意中出错的可能性，用户只应拥有执行其特定工作所需的权限。 有关详细信息，请参阅建议的安全做法。
  • 包括具有托管服务注册分配删除角色的授权，让你能够在需要时删除对委派的访问权限。 如果未分配此角色，则只能由客户租户中的用户移除对委派资源的访问权限。
  • 确保需要查看 Azure 门户中的“我的客户”页的所有用户都具有读取者角色（或者包含读取者访问权限的其他内置角色）。

重要

若要为 Microsoft Entra 组添加权限，“组类型”必须设置为“安全”。 此选项是在创建组时选择的。 有关详细信息，请参阅使用 Microsoft Entra ID 创建基本组并添加成员。

Azure Lighthouse 的角色支持

定义授权时，必须为每个用户帐户分配一个 Azure 内置角色。 不支持自定义角色和经典订阅管理员角色。

Azure Lighthouse 目前支持所有内置角色，但有以下例外：

  • 不支持所有者角色。

  • 支持用户访问管理员角色，但仅限用于向客户租户中的托管标识分配角色。 此角色通常会授予的其他权限不适用。 如果定义具有此角色的用户，则还必须指定该用户可分配给托管标识的角色。

  • 不支持具有 DataActions 权限的任何角色。

  • 不支持包含以下任何操作的角色：

    • Microsoft.Authorization/*
    • Microsoft.Authorization/*/write
    • Microsoft.Authorization/*/delete
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.Authorization/roleAssignments/删除
    • 微软.Authorization/roleDefinitions/write
    • Microsoft.Authorization/roleDefinitions/delete
    • Microsoft.Authorization/classicAdministrators/write
    • Microsoft.Authorization/classicAdministrators/delete (删除经典管理员)
    • Microsoft.Authorization/locks/write（这是指Microsoft授权服务中的一个路径或资源）
    • Microsoft.Authorization/locks/delete
    • Microsoft.Authorization/denyAssignments/write
    • Microsoft.Authorization/denyAssignments/delete

重要

分配角色时，请务必查看为每个角色指定的操作。 尽管不支持具有 DataActions 权限的角色，但在某些情况下，支持的角色中包含的操作可能允许访问数据。 当数据通过访问密钥公开，而不是通过用户标识进行访问时，通常会发生这种情况。 例如，虚拟机参与者角色包括 Microsoft.Storage/storageAccounts/listKeys/action 操作，该操作返回可用于检索某些客户数据的存储帐户访问密钥。

在某些情况下，之前受 Azure Lighthouse 支持的角色可能会变得不可用。 例如，如果将 DataActions 权限添加到以前没有该权限的角色，则在载入新委派时不能再使用该角色。 已分配有该角色的用户仍能够处理以前委派的资源，但他们无法执行使用 DataActions 权限的任何任务。

向 Azure 添加新的适用内置角色后，可以在使用 Azure 资源管理器模板加入客户时分配该角色。 发布托管服务产品/服务时，新添加的角色在合作伙伴中心内变得可用之前可能会出现延迟。 同样，如果某个角色变得不可用，在一段时间内可能仍会在合作伙伴中心看到该角色；但无法使用此类角色发布新产品/服务。

将委托订阅从一个 Microsoft Entra 租户转移到另一个租户

如果订阅转移到另一个 Microsoft Entra 租户帐户，则将保留通过 Azure Lighthouse 加入流程创建的注册定义和注册分配资源。 这意味着，通过 Azure Lighthouse 授予管理租户的访问权限对该订阅（或该订阅中的委派资源组）仍然有效。

唯一的例外情况是订阅转移到之前已委派给的 Microsoft Entra 租户。 在这种情况下，将移除该租户的委派资源，并且通过 Azure Lighthouse 授予的访问权限不再适用，因为订阅现在直属于该租户（而非通过 Azure Lighthouse 委派给该租户）。 但是，如果该订阅也委派给了其他管理租户，则其他管理租户将保留对订阅的相同访问权限。

后续步骤

  • Last updated on