通过自定义角色实现Azure操作权限的细分

Azure平台上为每个租户提供了Azure Active Directory服务（AAD），基于AAD提供了大量的内置角色，通过将这些角色分配给不同的操作人员来实现在一个租户内对各类资源操作权限的划分。然而当这些内置角色无法满足你的需求的时候，就可以通过自定义角色的方式来实现你的想法了。

（一）基本概念

在进入主题之前，还是先来澄清里面的概念要点和逻辑关系，当然，熟悉AAD和Azure的老司机可以跳过这段。

AD – Active Directory 活动目录，即一套标识/身份管理服务

AAD – Azure Active Directory，简单理解为AD在Azure云端的实现，但是这个是多租户的服务。

Role – 角色， 抽象的身份，对应一个权限集合

RBAC – Role based Access Control，基于角色的权限控制；这种方式已经是在IT平台上最为流行的方式了，就是权限与角色关联，控制权限实际是控制了角色，用户被赋予不同的角色，用户实际权限的体现是由用户所赋予的角色关联的权限。

每个 Azure 订阅都与一个 Azure Active Directory (AD) 目录相关联。 该目录中的用户、组和应用程序可以管理 Azure 订阅中的资源。 可以使用 Azure 门户、Azure 命令行工具和 Azure 管理 API 分配这些访问权限。

通过将相应的 RBAC 角色分配给特定范围内的用户、组和应用程序来授予访问权限。 角色分配的范围可以是订阅、资源组或单个资源。 分配在父范围内的角色也会将访问权限授予给其中所含的子范围。 例如，具有对资源组访问权限的用户可以管理其包含的所有资源，如网站、虚拟机和子网。

（二）内置角色

Azure RBAC 有三种适用于所有资源类型的基本角色：

• 所有者对所有资源具有完全访问权限，包括将访问权限委派给其他用户的权限。
• 参与者可以创建和管理所有类型的 Azure 资源，但不能将访问权限授予其他用户。
• 读者 可以查看现有的 Azure 资源。

关于内置角色的详细信息请参阅：

https://docs.azure.cn/zh-cn/active-directory/role-based-access-built-in-roles。

以备份服务为例（这个东东总是要求不同人有不同权限…..）:

备份参与者	可以管理恢复服务保管库中的备份
备份操作员	可以管理恢复服务保管库中的备份，删除备份除外
备份读者	可以查看所有备份管理服务

备份读者的操作：

操作
Micosoft.RecoveryServices/Vaults/backupFabrics/operationResults/read	读取备份管理操作的结果
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/operationResults/read	在保护容器上读取操作结果
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/operationResults/read	读取对备份项执行的操作的结果
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/operationStatus/read	读取对备份项执行的操作的状态
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/read	读取备份项
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/read	读取保存备份项的容器
Microsoft.RecoveryServices/Vaults/backupJobs/operationResults/read	读取备份作业的结果
Microsoft.RecoveryServices/Vaults/backupJobs/read	读取备份作业
Microsoft.RecoveryServices/Vaults/backupJobsExport/action	将备份作业导出到 Excel
Microsoft.RecoveryServices/Vaults/backupManagementMetaData/read	读取与备份管理相关的元数据
Microsoft.RecoveryServices/Vaults/backupOperationResults/read	读取备份管理操作结果
Microsoft.RecoveryServices/Vaults/backupPolicies/operationResults/read	读取对备份策略执行的操作的结果
Microsoft.RecoveryServices/Vaults/backupPolicies/read	读取备份策略
Microsoft.RecoveryServices/Vaults/backupProtectedItems/read	读取备份项
Microsoft.RecoveryServices/Vaults/backupProtectionContainers/read	读取保存备份项的备份容器
Microsoft.RecoveryServices/Vaults/extendedInformation/read	读取与保管库相关的扩展信息
Microsoft.RecoveryServices/Vaults/read	读取恢复服务保管库
Microsoft.RecoveryServices/Vaults/refreshContainers/read	读取用于获取新创建的容器的发现操作的结果
Microsoft.RecoveryServices/Vaults/registeredIdentities/operationResults/read	读取对保管库的注册项执行的操作的结果
Microsoft.RecoveryServices/Vaults/registeredIdentities/read	读取保管库的注册项
Microsoft.RecoveryServices/Vaults/usages/read	读取恢复服务保管库的使用情况

{这个太占篇幅了，所以就只能举一个例子了}

（三）自定义角色

终于到了主题了……如果上述的内置角色不符合你对角色细分的要求，可以创建自定义角色。 自定义角色的创建有三种方式：Azure PowerShell、Azure 命令行接口 (CLI) 和 REST API 创建自定义角色。（绝大部分Azure上的操作都是这样三种手段，至于用哪一个，看你自己的喜好了，下面用CLI为例）

l  自定义角色与内置角色一样，可以将自定义角色分配到订阅、资源组和资源范围内的用户、组和应用程序。

l  自定义角色存储在 Azure AD 租户中，可以在订阅之间共享。

l  限制：每个租户可以创建最多 2000 个自定义角色。

角色的三大属性：

1.       自定义角色的 Actions 属性指定该角色向其授予访问权限的 Azure 操作。 它是操作字符串的集合，可标识 Azure 资源提供程序的安全对象操作。 操作字符串遵循格式 Microsoft.<ProviderName>/<ChildResourceType>/<action>。 允许使用通配符 (*) 的操作字符串来授权访问与该操作字符串相匹配的所有操作。

2.       要排除受限制的操作可以使用 NotActions 属性。 通过用 Actions 操作减去 NotActions 操作可以得到自定义角色授予的访问权限。

3.     自定义角色的 AssignableScopes 属性指定可以分配该自定义角色的范围（订阅、资源组或资源）。 可以让自定义角色只在需要它的订阅或资源组中进行分配，而不影响其他订阅或资源组。

下面一个操作实例来说明如何创建和管理一个自定义角色。

（1）   设计一个自定义角色：

首先需要进行规划，这个自定义角色用来干什么？使用范围是什么？比如，我们给运维团队设计一个初级的备份管理员，这个管理员可以创建备份，但不允许他恢复备份（只是为了举例）

（2）   创建角色的JSON描述文件：

 

（3）   建自定义角色

azure role create --inputfile \code\sublime\newBackupRole.JSON

 

（4）   修改自定义角色

要修改自定义角色，使用 azure role show 命令检索角色。

然后，对角色定义JSON文件做出所需更改。 最后，使用 azure role set 保存修改后的角色定义。

 

（5）   删除自定义角色

同样，要删除自定义角色，使用 azure role show 命令查到要删除角色的 ID 。 然后，使用 azure role delete 命令通过指定 ID 来删除该角色。

（四）后记

Azure提供了大量的自定义能力，所以在满足用户需求方面拥有强大的灵活性。但是实施一个自定义的权限分配的根本还是在对权限模型的理解和良好的权限规划，这样才不会让自定义的角色、权限变成负担。