Azure资源Reader权限含义及RBAC继承覆盖规则问题咨询

1. Reader角色的权限范围，及仅持有Reader权限的服务主体能否正常使用Databricks工作区 #

• Reader是Azure内置的基础RBAC角色，核心权限范围仅覆盖资源控制平面的读取操作：可以查看所有资源的配置信息、监控数据、标签、部署记录等属性，不具备任何修改资源状态、写入数据、触发资源管理操作的权限，也无法直接访问资源的数据平面内容。
• 仅对Databricks工作区持有Reader权限的服务主体，完全无法正常使用工作区。该权限仅支持在Azure门户、API侧读取工作区的基础Azure属性（比如定价层、部署区域、关联VNet配置、资源ID），既无法跳转到Databricks独立的工作区控制台，也不能执行创建集群、运行Notebook、访问工作区内资产、配置作业等任何Databricks层面的操作，甚至无法读取工作区内部的用户、权限列表——Databricks有独立的数据平面权限体系，Azure层面的Reader连最基础的工作区登录权限都不具备。

2. 资源组Reader+存储资源Contributor的配置，能否满足用户创建存储容器的需求 #

• 该配置方案完全可行，属于符合最小权限原则的常规配置：
  • 资源组层面的Reader权限，作用是允许用户枚举、查看资源组下的所有资源列表和基础配置，避免出现用户打开资源组看不到对应存储账号的可见性问题；
  • 存储账号层面的Contributor权限，已经覆盖存储账号控制平面的绝大多数操作，包括在存储账号下创建/删除容器、配置生命周期规则、调整冗余选项、配置防火墙规则等，创建容器属于存储账号的子资源管理操作，完全在该角色的权限范围内，不需要额外给资源组授予更高等级的权限。
• 需要注意的权限边界：该配置下用户无法删除存储账号本身，也无法给存储账号分配其他RBAC角色，这两类操作需要对应级别的权限写入和资源删除权限，如果没有这两类操作需求，现有配置完全满足创建容器的要求。

3. 子资源层级能否单独配置权限，覆盖父级继承的RBAC权限 #

• Azure RBAC完全支持在子资源层级单独分配权限，你描述的「资源组层授予Reader，组内特定资源单独授予Contributor」的配置可以正常生效：
  • RBAC的默认继承逻辑是：父级范围（管理组、订阅、资源组）分配的允许类角色权限，会自动传递到所有下级资源，但继承的权限不是强制锁定的，你可以在任意子资源层级单独做角色分配。用户对某个资源的最终有效权限，是从根管理组到目标资源所有层级分配的允许角色权限的并集。
  • 上述配置场景中，用户对特定资源的权限为「继承自资源组的Reader权限」+「子资源单独授予的Contributor权限」，两类权限合并后，用户对该资源拥有完整的Contributor操作权限，不会被父级的Reader权限限制。
  • 唯一的例外情况：如果父级范围配置了拒绝分配（Deny Assignment） 规则（比如Azure Policy强制的拒绝规则、Azure蓝图分配的锁定规则），这类拒绝规则优先级高于所有允许类权限，子资源层级的允许角色分配无法覆盖这类拒绝规则，但普通的允许类角色分配不存在该限制。

内容的提问来源于stack exchange，提问作者MetallicPriest