来分享一个比较简单的case，来自于实际的用户需求，在Azure中最常用的几个role包括owner，contributor，reader等等，一般情况下，除了整个cloud的管理员以外，我们一般很少直接assign owner这种权限给用户，因为owner意味着最大的权限，用户甚至还可以把权限assign给其他用户，这样整个环境很容易失控，所以一般情况下给到contributor这个role就足够了，至于两者的区别，简单理解就是contributor除了不能给用户assign权限之外，其他大部分的事情都可以做，用来做Azure resource的管理是足够了
但是今天这个case就有点特殊，背景是这个用户本身已经有了contributor的权限，同时用户还希望能够给资源添加lock，防止资源被意外删除，给资源加lock这个操作本身是只有owner这个role才有的，但是owner这个role又包含了给其他用户添加权限的权限，直接给owner权限无疑太大了。
这种场景是用一些自定义的role就比较合适了，我们可以在contributor的基础上再给用户单独加上添加lock的权限，这样就能很好控制权限的边界了
方法其实也并不复杂，以在portal的操作为例，首先先到subscription中的IAM里，然后添加一个custom role
直接从contributor role进行clone
删掉这两个，然后选择exclude permissions
搜索Microsoft.Authorization
勾选全部，然后只保留lock相关的
直接创建
然后尝试着用刚才创建的role给用户赋权
授权之后，登录可以发现刚才exclude权限的时候加的有点多，限制的有点死，把read权限也删掉了，这个可以根据实际需要调整下
最后测试可以发现，用户可以正常进行资源的管理，同时还可以给资源添加lock
这样用户的需求就实现了，当然权限的添加还是要保持慎重的，这里只是举个简单的例子，如果是生产环境，一定要谨慎测试之后再进行赋权
