在微服务系统开发部署中使用Azure RBAC自定义角色
Azure的官方文档介绍了如何创建用于Azure基于角色的访问控制的自定义角色（RBAC Role）。 我们也可以根据同样的原理把RBAC细粒度资源管理运用于微服务产品的开发部署中。（https://www.azure.cn/documentation/articles/role-based-access-control-custom-roles/）
由于快速变化的业务需求，微服务的系统架构设计经常会发生变化，开发团队常常需要增加一个新的微服务，降级一个旧版本的微服务，把一个微服务分隔成2个。。。而在这个敏捷发布过程中，基础架构则相对稳定，变动较少。而当开发需要在云平台快速地开发调试部署新的微服务的时候，运维则非常担心拥有云资源权限的开发会误删网络，NSG之类的基础架构从而影响到测试环境生产环境的稳定性。我们常常可以看到运维团队坚决反对给开发团队开放权限。
Azure提供的RBAC 自定义角色通过赋予开发所需的最小权限集很好的解决了这个问题。让我们来看一个简单的实例。
我们的系统将部署在Azure的资源组Meow和MeowNetwork中。 MeowNetwork资源组目前包括一个Vnet，其中有2个子网，microservicesubnet用于部署微服务·，GatewaySubnet则用于一些基础设施，比如和公司onpremises网络的连接，我们还可以在这个资源组里加入子网的NSG。Meow资源组则用于部署应用系统比方虚拟机和存储账号。
接下来的任务就是由开发在子网1里部署微服务了。先来分析一下开发需要/不需要什么样的权限。
开发能够看到和操作整个MeowMeow应用系统的资源，这会帮助他们了解整个系统
开发能够在vnet里添加虚拟机并做监测
只有运维可以改动删除vnet，subnet和gatewaysubnet等基础设施的权限
我们先分配资源组Meow参与者和资源组MeowNetwork的网络参与者权限给一个“test”用户
用这个用户账号登录azure后，我们试试能不能在Meow资源组里创建一个虚拟机加入虚拟网
很好，新的vm加入到子网microservicesubnet.
我们再看看这个用户能不能改vnet设置，试试看删一下gateway子网
删掉了！！！
显然把资源组MeowNetwork的网络参与者的权限给用户“test”不是一个好主意。我们需要更细粒度的权限集，这就需要我们使用自定义RBAC角色。
针对我们的需求，最小的权限集应该是所有读取权限加上虚拟机“Virtual Network Subnet -》 其他操作-》Join Virtual Network”的权限
参考http://www.cnblogs.com/hengwei/p/5874776.html来定义一个新的 Virtual Network Joiner 的role. 代码如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | $role = Get-AzureRmRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Virtual Network Joiner"
$role.Description = "Join application (vm) to the existing virtual network"
$role.Actions.Add("Microsoft.Network/virtualNetworks/subnets/join/action")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/你的subscription id")
New-AzureRmRoleDefinition -Role $role
New-AzureRmRoleAssignment -SignInName 用户的sign in name -Scope /subscriptions/你的subscription id/resourceGroups/MeowNetwork -RoleDefinitionName "Virtual Network Joiner"
|
此时用户拥有资源组Meow参与者和资源组MeowNetwork的“Virtual Network Joiner”权限，再测试一下，虚拟机可以创建
再看看能不能删子网
显然从管理门户上根本看不到删除选项，成功^_^
题外话： 在测试过程中我们注意到，powershell创建并分配role后权限是立即生效的，但是管理门户上过了半小时左右才显示出这个新创建的role。
总结：
随着越来越多的公司开始实施DevOps，对开发团队开放云平台的权限势在必行。
一个细粒度的资源管理很好地支持并保障了多team合作项目的平稳运行。