通过

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

使用 REST API 分配 Azure 角色

  • 项目

Azure 基于角色的访问控制 (Azure RBAC) 是用于管理 Azure 资源访问权限的授权系统。 若要授予访问权限，请将角色分配给特定范围内的用户、组、服务主体或托管标识。 本文介绍如何使用 REST API 分配角色。

必备条件

若要分配 Azure 角色，必须具有：

必须使用以下版本：

  • 2015-07-01 或更高版本，用于分配 Azure 角色
  • 2018-09-01-preview 或更高版本，用于将 Azure 角色分配给新的服务主体

有关详细信息，请参阅 Azure RBAC REST API 的 API 版本。

分配 Azure 角色

若要分配角色，请使用角色分配 - Create REST API 并指定安全主体、角色定义和范围。 若要调用此 API，必须有权访问 Microsoft.Authorization/roleAssignments/write 操作，例如基于角色的访问控制管理员。

  1. 使用角色定义 - List REST API 或参阅内置角色，获取你想要分配的角色定义的标识符。

  2. 使用 GUID 工具生成将用于角色分配标识符的唯一标识符。 标识符的格式为：00000000-0000-0000-0000-000000000000

  3. 从以下请求和正文开始：

    PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}?api-version=2022-04-01

    {
  "properties": {
    "roleDefinitionId": "/{scope}/providers/Microsoft.Authorization/roleDefinitions/{roleDefinitionId}",
    "principalId": "{principalId}"
  }
}

  4. 在 URI 内，将“{scope}”替换为角色分配的范围。

    作用域 类型
    providers/Microsoft.Management/managementGroups/{groupId1} 管理组
    subscriptions/{subscriptionId1} 订阅
    subscriptions/{subscriptionId1}/resourceGroups/myresourcegroup1 资源组
    subscriptions/{subscriptionId1}/resourceGroups/myresourcegroup1/providers/microsoft.web/sites/mysite1 资源

    在前面的示例中，microsoft.web 是引用应用服务实例的资源提供程序。 同样，可以使用任何其他资源提供程序并指定范围。 有关详细信息，请参阅 Azure 资源提供程序和类型和支持的 Azure 资源提供程序操作。

  5. 将“{roleAssignmentId}”替换为角色分配的 GUID 标识符。

  6. 在请求正文中，将 {scope} 替换为与 URI 中相同的范围。

  7. 将“{roleDefinitionId}”替换为角色定义标识符。

  8. 将“{principalId}”替换为将分配有角色的用户、组或服务主体的对象标识符。

以下请求和正文将备份读取者角色分配给订阅范围内的用户：

PUT https://management.azure.com/subscriptions/{subscriptionId1}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId1}?api-version=2022-04-01

{
  "properties": {
    "roleDefinitionId": "/subscriptions/{subscriptionId1}/providers/Microsoft.Authorization/roleDefinitions/a795c7a0-d4a2-40c1-ae25-d81f01202912",
    "principalId": "{objectId1}"
  }
}

下面显示了输出示例：

{
    "properties": {
        "roleDefinitionId": "/subscriptions/{subscriptionId1}/providers/Microsoft.Authorization/roleDefinitions/a795c7a0-d4a2-40c1-ae25-d81f01202912",
        "principalId": "{objectId1}",
        "principalType": "User",
        "scope": "/subscriptions/{subscriptionId1}",
        "condition": null,
        "conditionVersion": null,
        "createdOn": "2022-05-06T23:55:23.7679147Z",
        "updatedOn": "2022-05-06T23:55:23.7679147Z",
        "createdBy": null,
        "updatedBy": "{updatedByObjectId1}",
        "delegatedManagedIdentityResourceId": null,
        "description": null
    },
    "id": "/subscriptions/{subscriptionId1}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId1}",
    "type": "Microsoft.Authorization/roleAssignments",
    "name": "{roleAssignmentId1}"
}

新服务主体

如果创建新服务主体并立即尝试将角色分配给该服务主体，则在某些情况下该角色分配可能会失败。 例如，如果创建新的托管标识，然后尝试将角色分配给该服务主体，则角色分配可能会失败。 失败原因可能是复制延迟。 服务主体是在一个区域中创建的；但是，角色分配可能发生在尚未复制服务主体的其他区域中。

若要解决这种情况，请使用角色分配 - 创建 REST API 并将 principalType 属性设置为 ServicePrincipal。 还必须将 apiVersion 设置为 2018-09-01-preview 或更高版本。 2022-04-01 是第一个稳定版本。

PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}?api-version=2022-04-01

{
  "properties": {
    "roleDefinitionId": "/{scope}/providers/Microsoft.Authorization/roleDefinitions/{roleDefinitionId}",
    "principalId": "{principalId}",
    "principalType": "ServicePrincipal"
  }
}

后续步骤