在微服务系统开发部署中使用Azure RBAC自定义角色

2022-12-12,,,,

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. 代码如下:

#获取"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合作项目的平稳运行。

在微服务系统开发部署中使用Azure RBAC自定义角色的相关教程结束。

《在微服务系统开发部署中使用Azure RBAC自定义角色.doc》

下载本文的Word格式文档,以方便收藏与打印。