使用 REST API 分配 Azure 角色
Azure 基于角色的访问控制 (Azure RBAC) 是用于管理 Azure 资源访问权限的授权系统。 若要授予访问权限,请将角色分配给特定范围内的用户、组、服务主体或托管标识。 本文介绍如何使用 REST API 分配角色。
必备条件
若要分配 Azure 角色,必须具有:
Microsoft.Authorization/roleAssignments/write
权限,例如基于角色的访问控制管理员或用户访问管理员
必须使用以下版本:
2015-07-01
或更高版本,用于分配 Azure 角色2018-09-01-preview
或更高版本,用于将 Azure 角色分配给新的服务主体
有关详细信息,请参阅 Azure RBAC REST API 的 API 版本。
分配 Azure 角色
若要分配角色,请使用角色分配 - Create REST API 并指定安全主体、角色定义和范围。 若要调用此 API,必须有权访问 Microsoft.Authorization/roleAssignments/write
操作,例如基于角色的访问控制管理员。
使用角色定义 - List REST API 或参阅内置角色,获取你想要分配的角色定义的标识符。
使用 GUID 工具生成将用于角色分配标识符的唯一标识符。 标识符的格式为:
00000000-0000-0000-0000-000000000000
从以下请求和正文开始:
PUT https://management.chinacloudapi.cn/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}?api-version=2022-04-01
{ "properties": { "roleDefinitionId": "/{scope}/providers/Microsoft.Authorization/roleDefinitions/{roleDefinitionId}", "principalId": "{principalId}" } }
在 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 资源提供程序操作。
将“{roleAssignmentId}”替换为角色分配的 GUID 标识符。
在请求正文中,将 {scope} 替换为与 URI 中相同的范围。
将“{roleDefinitionId}”替换为角色定义标识符。
将“{principalId}”替换为将分配有角色的用户、组或服务主体的对象标识符。
以下请求和正文将备份读取者角色分配给订阅范围内的用户:
PUT https://management.chinacloudapi.cn/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.chinacloudapi.cn/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}?api-version=2022-04-01
{
"properties": {
"roleDefinitionId": "/{scope}/providers/Microsoft.Authorization/roleDefinitions/{roleDefinitionId}",
"principalId": "{principalId}",
"principalType": "ServicePrincipal"
}
}