2015 年 10 月份,微软宣布 Azure 基于角色的访问控制(RBAC)功能已完成了通用版本。开发此功能的目的是为组织提供更精准的粒度,尤其是当个人或团体访问 Azure 资源和服务器的时候。
RBAC 可以提供中心治理模式,这个中心治理模式意即 IT 维护部门可以对云环境进行总体控制,可以利用团队所具有的访问服务器的级别来分配 DevOps 或项目。微软项目经理 Dushyant Gill 进一步解释说,“使用 Azure RBAC,就能实现项目团队的云资源自助管理,同时还能保留对安全基础设施的集中控制权。举例来说,项目团队创建和管理自己的虚拟机和存储帐户需要一个共同的设置是,而这个设置必须要连接到中央管理网络。”
正如微软高级技术开发者 Ingrid Henkel 所说的那样,微软在分配权限给不同身份和团队的时候,使用分层的方法,“Azure 里的每一个订阅都仅属于一个目录,每个资源组都只属于一个订阅,并且每一个资源也只属于一个资源组。”
一旦使用 RBAC,用户就只有通过分配到的合适的 RBAC 角色才能在正确的范围内访问。一个用户只需要访问特定资源,而不能访问订阅中的其他资源。
从历史上看,在经典的订阅模式里,管理员和联合管理员具有访问 Azure 订阅的全部权限。这往往会导致企业用户有更多的可访问的内容。在新的 RBAC 模型中,有 3 种基本的内置角色:
- RBAC 角色拥有者有充分的资源和授权访问能力
- 访问贡献者可以创建和管理 Azure 资源,但不能授权访问
- 授权访问的读者只能查看现有的 Azure 资源
经典模型中的管理员在 RBAC 模型中其实已经拥有所有者权限了。除了这些基本的内置功能,微软为具体的产品和服务发布了一个完整的内置角色清单,例如包括 SQL 数据库和网络贡献者。
RBAC 模型不仅支持权限继承,还能将权限继续从订阅级联到资源组。如果将继承权限应用于某个资源组,则该权限级别将属于该资源组。如果权限被继承,只有最高级别的管理者才能对其权限栈进行修改。RBAC 权限在很多经典入口是找不到的,但是却可以在新的 Azure 入口分配。RBAC 权限还可以被应用于使用 PowerShell 或 Azure 的命令行界面。
对于具备自定义功能的组织方来说,他们有能力使用 RBAC 命令行工具。这有点像内置功能,可以分配给用户、团队和应用程序。在下图中,有一个被称为 Virtual Machine Operator 的自定义规则,提供所有必要的权限或操作来监视和重启虚拟机。
微软还提供了一份报告,这份报告指出组织应该从整体角度看待在过去 90 天里所有已经授权或已撤销的权限。
查看英文原文: Azure Role-based Access Control Reaches General Availability
感谢艾利特对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。
评论