使用角色控制资源访问
Azure 资源的内置角色(使用 PowerShell)
Azure 提供了若干内置角色,以涵盖最常见的安全性方案。 为了了解角色的工作原理,让我们来研究一下适用于所有资源类型的三种角色:
- 所有者:拥有对所有资源的完全访问权限,包括将访问权限委派给其他用户的权限。
- 参与者:可以创建和管理所有类型的 Azure 资源,但无法将访问权限授予其他用户。
- 读者:可以查看现有的 Azure 资源。
角色定义
每个角色都是在 JavaScript 对象表示法 (JSON) 文件中定义的一组属性。 此角色定义包括“名称”、“ID”和“说明”。 其中还包括角色的可用权限 (Actions)、拒绝权限 (NotActions) 和范围(例如,读取访问)。
对于所有者角色,即表示所有操作(用星号 (*) 表示);没有拒绝的操作;以及所有范围(以正斜杠 (/) 表示)。
可使用 PowerShell Get-AzRoleDefinition Owner
cmdlet 获取此信息。
Get-AzRoleDefinition Owner
此代码应生成以下输出:
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
尝试对“参与者”和“读者”角色执行相同的操作,以查看允许和拒绝的操作。
内置角色
有关 Microsoft Entra ID 中 RBAC 和用户角色的深入检查,请参阅在 Microsoft Entra ID 中检查 RBAC 和用户角色。
什么是角色定义?
角色定义是权限的集合。 角色定义列出了角色可执行的操作,例如读取、写入和删除。 它还可以列出不能执行的操作或与基础数据相关的操作。
如前所述,角色定义具有以下结构:
名称 | 说明 |
---|---|
Id |
角色的唯一标识符,由 Azure 分配 |
IsCustom |
如果这是一个自定义角色,则为 True;如果这是一个内置角色,则为 False |
Description |
角色的可读说明 |
Actions [] |
允许的权限,* 表示所有权限 |
NotActions [] |
拒绝的权限 |
DataActions [] |
应用于数据的特定允许权限,例如 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read |
NotDataActions [] |
应用于数据的特定拒绝权限。 |
AssignableScopes [] |
此角色适用的范围;/ 表示全局,但可以访问分层树 |
在基于角色的访问控制 (RBAC) 或基础 API 中使用时,此结构表示为 JSON。 例如,下面是 JSON 格式的参与者角色定义。
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Actions 和 NotActions
可以定制 Actions
和 NotActions
属性,以授予和拒绝所需的确切权限。 这些属性的格式始终为 {Company}.{ProviderName}/{resourceType}/{action}
。
例如,下面是前面介绍的三个角色的操作:
内置角色 | Actions | NotActions |
---|---|---|
所有者(允许执行所有操作) | * |
- |
参与者(允许执行除编写或删除角色分配之外的所有操作) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
读者(允许执行所有读取操作) | */read |
- |
Actions
下的通配符 (*
) 操作表示分配给此角色的主体可以执行所有操作,换句话说,此角色可以管理所有内容,其中包括将来在将新资源类型添加到 Azure 时定义的操作。 使用“读者”角色,仅允许 read
操作。
NotActions
下的操作会从 Actions
中去除。 使用“参与者”角色,NotActions
可删除此角色管理资源访问权限以及分配资源访问权限的功能。
DataActions 和 NotDataActions
数据操作在 DataActions
和 NotDataActions
属性中指定。 可以指定独立于管理操作的数据操作。 这可防止包含通配符 (*
) 的当前角色分配突然访问数据。 下面是一些可在 DataActions
和 NotDataActions
中指定的数据操作:
- 读取容器中的 Blob 列表
- 在容器中写入存储 Blob
- 删除队列中的消息
只能向 DataActions
和 NotDataActions
属性添加数据操作。 资源提供程序通过将 isDataAction
属性设置为 true
来识别哪些操作是数据操作。 没有数据操作的角色可以忽略角色定义中的这些属性。
这些操作的处理方式与其管理方式完全相同。 可指定要允许的操作(*
表示全部操作),然后提供要从 NotDataActions
集合中删除的特定操作的列表。 下面是一些示例,可以在资源提供程序文档中找到操作和数据操作的完整列表:
数据操作 | 说明 |
---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
删除 blob数据 |
Microsoft.Compute/virtualMachines/login/action |
以普通用户身份登录 VM |
Microsoft.EventHub/namespaces/messages/send/action |
在事件中心发送消息 |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
返回文件/文件夹或文件/文件夹列表 |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
从队列中读取消息 |
可分配范围
定义 Actions 和 NotActions 属性不足以完全实现角色。 还需要适当地确定角色的范围。
角色的 AssignableScopes 属性指定角色可供分配的范围(订阅、资源组或资源)。 可以使自定义角色仅在需要它的订阅或资源组中可供分配,从而避免影响其他订阅或资源组的用户体验。
下面是一些示例:
To | 使用范围 |
---|---|
限制为订阅 | "/subscriptions/{sub-id}" |
限制为特定订阅中的特定资源组 | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
限制为特定资源 | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
使角色在两个订阅中可供分配 | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
创建角色
Microsoft Entra ID 附带有内置角色,可能涵盖了想要执行的 99% 的操作。 如果可能,请首选使用内置角色。 但是,如有必要,可以创建自定义角色。
注意
创建自定义角色需要 Microsoft Entra ID P1 或 P2;无法在免费层中创建自定义角色。
可以通过多种机制创建新角色:
Microsoft Entra 管理中心:可以在左侧菜单中“角色和管理员”下选择“角色和管理员”,然后选择“新的自定义角色”,以使用 Microsoft Entra 管理中心创建自定义角色。
Azure 门户:可以使用 Azure 门户,通过选择“Microsoft Entra ID”>“角色和管理员”>“新建自定义角色”来创建自定义角色。
Azure PowerShell:可以使用
New-AzRoleDefinition
cmdlet 定义新角色。Azure Graph API:可以使用对图形 API 的 REST 调用以编程方式创建新角色。
本模块的“摘要”部分包含这些方法的文档链接。