了解 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"
}

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

作用域

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

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

要分配的角色

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

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

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

主体

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

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

名称

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

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

资源删除行为

从 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)？

后续步骤

• 分配 Azure 角色的步骤