通过

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

了解 Azure 角色分配

  • 项目

通过角色分配，可以授予主体（例如用户、组、托管标识或服务主体）对特定 Azure 资源的访问权限。 本文介绍角色分配的详细信息。

角色分配

对 Azure 资源的访问权限是通过创建角色分配来授予的，并且这些访问权限是通过删除角色分配来撤销的。

角色分配有多个组成部分，包括：

  • 分配有角色的“主体”或“人员”。
  • 分配给他们的“角色”。
  • 分配角色的“范围”。
  • 角色分配的“名称”，以及帮助你解释分配角色的原因的“说明”。

例如，可以使用 Azure RBAC 分配角色，例如：

  • 用户 Sally 对资源组“ContosoStorage”中的存储帐户“contoso123”拥有所有者访问权限。
  • Microsoft Entra ID 的“云管理员”组中的每个人都对资源组“ContosoStorage”中的所有资源拥有读取者访问权限。
  • 允许与应用程序关联的托管标识在 Contoso 的订阅内重新启动虚拟机。

以下示例展示了在 Azure PowerShell 中显示的角色分配属性：

{
  "RoleAssignmentName": "00000000-0000-0000-0000-000000000000",
  "RoleAssignmentId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "Scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "DisplayName": "User Name",
  "SignInName": "user@contoso.com",
  "RoleDefinitionName": "Contributor",
  "RoleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "ObjectId": "22222222-2222-2222-2222-222222222222",
  "ObjectType": "User",
  "CanDelegate": false,
  "Description": null,
  "ConditionVersion": null,
  "Condition": null
}

以下示例展示了在 Azure CLI 或 REST API 中显示的角色分配属性：

{
  "canDelegate": null,
  "condition": null,
  "conditionVersion": null,
  "description": null,
  "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "name": "00000000-0000-0000-0000-000000000000",
  "principalId": "22222222-2222-2222-2222-222222222222",
  "principalName": "user@contoso.com",
  "principalType": "User",
  "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "roleDefinitionName": "Contributor",
  "scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "type": "Microsoft.Authorization/roleAssignments"
}

下表说明了角色分配属性的含义。

属性 说明
RoleAssignmentName
name		 角色分配的名称，它是全局唯一标识符 (GUID)。
RoleAssignmentId
id		 角色分配的唯一 ID，其中包括名称。
Scope
scope		 角色分配的范围限定到的 Azure 资源标识符。
RoleDefinitionId
roleDefinitionId		 角色的唯一 ID。
RoleDefinitionName
roleDefinitionName		 角色的名称。
ObjectId
principalId		 分配到角色的主体的 Microsoft Entra 对象标识符。
ObjectType
principalType		 主体表示的 Microsoft Entra 对象的类型。 有效值包括 User、Group 和 ServicePrincipal。
DisplayName 对于用户的角色分配，则是用户的显示名称。
SignInName
principalName		 用户的唯一主体名称 (UPN)，或者与服务主体关联的应用程序的名称。
Description
description		 角色分配的说明。
Condition
condition		 使用角色定义和属性中的一个或多个操作生成的条件语句。
ConditionVersion
conditionVersion		 条件版本号。 默认为 2.0，这是唯一受支持的版本。
CanDelegate
canDelegate		 未实现。

作用域

当创建角色分配时，需要指定它的应用范围。 范围代表主体可以访问的资源或资源集。 可以将角色分配的范围限定为单个资源、资源组、订阅或管理组。

提示

使用满足要求所需的最小范围。

例如，如果需要向单个存储帐户授予托管标识访问权限，好的安全的做法是在存储帐户范围内创建角色分配，而不是在资源组或订阅范围内创建角色分配。

有关范围的详细信息，请参阅了解范围。

要分配的角色

角色分配与角色定义相关联。 角色定义指定了主体在角色分配范围内应该拥有的权限。

可以分配内置角色定义或自定义角色定义。 创建角色分配时，一些工具会要求你使用角色定义 ID，而其他工具允许你提供角色的名称。

有关角色定义的详细信息，请参阅了解角色定义。

主体

主体包括用户、安全组、托管标识、工作负载标识和服务主体。 主体是在 Microsoft Entra 租户中创建和管理的。 你可以向任一主体分配角色。 使用 Microsoft Entra ID“对象 ID”识别要向其分配角色的主体。

使用 Azure PowerShell、Azure CLI、Bicep 或其他基础结构即代码 (IaC) 技术创建角色分配时，需指定“主体类型”。 主体类型包括“User”、“Group”和“ServicePrincipal”。 请务必指定正确的主体类型。 否则，可能会遇到间歇性部署错误，尤其是在使用服务主体和托管标识时。

名称

角色分配的资源名称必须是全局唯一标识符 (GUID)。

角色分配资源名称在 Microsoft Entra 租户中必须是唯一的，即使角色分配的范围较窄，也是如此。

提示

当使用 Azure 门户、Azure PowerShell 或 Azure CLI 创建角色分配时，创建过程会自动为角色分配指定唯一的名称。

如果通过使用 Bicep 或其他基础结构即代码 (IaC) 技术来创建角色分配，则需要对角色分配的命名方式进行仔细的规划。 有关详细信息，请参阅使用 Bicep 创建 Azure RBAC 资源。

资源删除行为

从 Microsoft Entra ID 中删除用户、组、服务主体或托管标识时，最好删除所有角色分配。 不会自动删除它们。 引用已删除主体 ID 的任何角色分配都会变得无效。

如果尝试对另一个角色分配重复使用角色分配的名称，则部署会失败。 当使用 Bicep 或 Azure 资源管理器模板（ARM 模板）来部署角色分配时，此问题更有可能发生，因为当使用这些工具时，你必须显式设置角色分配名称。 若要解决此问题，应在重新创建旧角色分配之前删除旧角色分配，或者确保在部署新角色分配时使用唯一名称。

说明

可以向角色分配添加文本说明。 虽然说明是可选的，但是最好将它们添加到角色分配中。 提供简短的理由解释主体为何需要分配的角色。 当相关人员审核角色分配时，这些说明可以帮助其了解为何创建这些角色以及这些角色是否仍然适用。

条件

一些角色支持“角色分配条件”，这些条件基于特定操作的上下文中的属性。 角色分配条件是一项额外检查，你可选择将其添加到角色分配中，来提供更精细的访问控制。

例如，你可以添加一个条件，要求某一对象具有特定的标记，以便用户读取该对象。

我们通常使用可视化对象条件编辑器来生成条件，不过下面的示例展示的是代码中的条件：

((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'} AND NOT SubOperationMatches{'Blob.List'})) OR (@resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'))

上述条件允许用户读取 Blob 索引标记键为“Project”且值为“Cascade”的 Blob。

有关条件的详细信息，请参阅什么是 Azure 基于属性的访问控制 (Azure ABAC)？

后续步骤