上周五更新一篇《Azure ARM 架构深度解析》也因为是第一篇关于Azure的技术文章，写的很简单，基本以理论概念通篇，关于Resource Group，资源管理模式写的也是个大概，还有Resource Management里的Tags, Move rules, Export template 没有写进去（后期再补一篇），还有整个Azure大框架下，详细的权限之间的关系也是概括的描述，没有设置留言功能，以至于小伙伴们来了十几条私信，征求详细介绍Azure 角色控制。
这篇文章我们会详细的介绍下Azure 里ARM部署模式下，何为角色控制，每个Role之间的关系。谈起Azure ARM角色控制，如果想深刻认识它，我觉得我们应该先从宏观上认识Azure的架构。
Azure 管理结构图：
注意图片部分，上端部门红色板块，为Azure对于用户UI的直接呈现。
Azure里有三大管理门户，大家最为熟悉的为Azure Management Portal，也许了解EA，那么简单普及一下哈，就针对国内现在的Azure为例:
Azure Management Portal：https://manage.windowsazure.cn
Enterprise portal：https://ea.windowsazure.cn
Account portal：https://portal.partner.microsoftonline.cn
三大门户之间如何关联呢？是通过AD，账户信息是同步的，新的portal正在更新么，将来都会很好的正好到新门户里，向Global看齐一直是我们的方向！
所以，我们不难发现EA admin是最高权限，畅通无阻。Azure portal 里Subscription admin我的地盘我做主。其中很详细的User Role我们通过AD去定义的，也是MS的一套体系，这个毋庸置疑。
接下来我们来探讨下Azure ARM 基于角色控制访问，又称为Azure RBAC(Role Based Access Control)
因为ARM在资源分配管理权限级别为User提供了更细粒度的Role，是基于角色的访问控制(RBAC)模型实现的。
其实Role的Right流为：Subscription—à Resource Group --à Resource。那我们简单的看下，其实Role的最佳实践是通过Portal 或者ARM API来使用Resource Group。
Subscription级别：
参与者是AAD(Azure AD)里的Users，所有者是AAD里的User，读者是AAD Group里的成员，
这些Role需要我们自己添加，但要符合以上Rule才可以。
Resource Group级别：
Resource级别：
综上所述：完整的如下图。
详细请参阅：
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-built-in-roles/
按节点分配Role的好处: 现状因为可以Map现有的组织角色（Web，数据库…）到他们的云解决方案一般情况下，许多资源是同一个资源组的里，例如：虚拟机和存储帐户、Web应用和Appinsights要完，如果要管理一个资源，用户也可能需要管理其相关的节点来定义Role，
例如：DBA只能访问SQL相关，Dev只能访问Dev的RP资源等，对于整个组织有相当项目的意义。
以后会把ARM架构下VM，变化的，更新出来的Extensions, 更新进博客中。
