在微服务系统开发部署中使用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里部署微服务了。先来分析一下开发需要/不需要什么样的权限。

1. 开发能够看到和操作整个MeowMeow应用系统的资源，这会帮助他们了解整个系统
2. 开发能够在vnet里添加虚拟机并做监测
3. 只有运维可以改动删除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. 代码如下：

#获取"Reader"配置
$role = Get-AzureRmRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Virtual Network Joiner"
$role.Description = "Join application (vm) to the existing virtual network" 

#加入“Join Subnet”的权限
$role.Actions.Add("Microsoft.Network/virtualNetworks/subnets/join/action") 

#把Subscription加入到这个Role管理范围中
$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合作项目的平稳运行。