目录
一、背景
为了 Nacos 提升安全能力，更好满足生产要求，需要设计账号权限体系，又要能兼容云上和阿里内部场景。避免后续代码无法融合。 这块的挑战是要做好抽象，不然没法和不同账号权限体系打通。默认我们提供⼀个简单的实现，当有类似于 RAM 这样的权限体系后，直接对接即可。
1、账号体系
目前用的比较多的是 ABAC 和 RBAC 体系。目前阿里云采用 ABAC 体系，阿里内部采用 RBAC体系。无论哪个体系，最终都是让账号有有限资源的权限，已达到访问控制的目的。不同的是关联的方法，相同的都是抽象好 Nacos 的 Resource 和 Opers 。鉴权模块可以抽象可插拔，实现两种都可以支持。
2、账号实体映射
实体 阿里云账号 阿里内 Dauth 开源 公司 公司账号 ⼀个 admin 账号 业务域（BU，
产品线）用户组 CMDB 打通做
封网APP（程序和
负责人）子账号（程序账号和人账号） Dauth 应用账
号普通账号+角色 环境 namespace 同左 同左 资源 acs:config:region:namespace:group 同左 同左
二、方案
1、Nacos 资源模型
2、Nacos 授权 resource
namespace+group+dataId 组成某⼀个授权资源，是最细能做到的水准，但是这么细的授权粒度，会导致权限数据暴涨，有多少配置（100w），就会有多少授权数据，这样在分布式权限系统中是不能搞定的,因为要有 100w 授权数据，意味着我每个 nacos 节点要监听 100w 个权限数据。因此权限管控粒度在实际生产环境，只能控制到 group 级别。namespace+group。或者 namespace 级别。
2.1、授权 resource 组成
acs:config:region:namespace:group
acs: access controller system 缩写
config：产品名或者模块名
region：区域
namespace：命名空间
group：分组
2.2、不同级别授权资源组成
授权⼀个命名空间下所有数据权限
acs:config:region:namespace:* 授权多个命名空间下⼀个分组权限
acs:config:region:*:group
3、Nacos 授权 Opers
由于使用 nacos 本质是读写数据，监听也是⼀种为了读取的行为。因此对于具体某⼀个数据，只要区分到读或者写(w/r)即可。
4、Nacos 具体权限定义
4.1、Opers 组成
acs:config:region:namespace:group w/r
4.2、具体实例
角色/策略 Opers/Rule app1 app1Progress acs:config:region:namespace1:goup1 -> r app1console app1consoleProgress acs:config:region:namespace1:goup1 -> w user1 app1Dev acs:config:region:namespace1:goup1 -> r app2 app2Progress acs:config:region:namespace2:goup2 -> r app2console app2consoleProgress acs:config:region:namespace2:goup2 -> w user2 app2Dev acs:config:region:namespace2:goup2 -> r user3 app1Ops
app2Opsacs:config:region:namespace1:goup1 -> w
acs:config:region:namespace2:goup2 -> w
4.3、工程实现
所有的数据请求，都走鉴权切面。 切面里面抽象好 spi，实现上面的鉴权行为。 不同权限模型，不同场景，插拔不同的 spi。
三、RBAC 设计实现
1、RBAC 账号权限组成
rbac 账号体系由 账号 角色 权限，三元组构成，下面介绍该体系模型下，nacos 权限模型的最佳实践。
1.1、角色
首先从角色讲起，以便把账号，权限做⼀个大致的区分。
角色 实体映射 ⽤途 权限 SystemRole 系统运维工程师 运维 日常运维
查看系统 metrics
监控，处理报警
创建 AdminRole 的用户，或者提供开通
AdminRole 角色用户机制AdminRole 企业账号 付费， 创建员工账号
分配权限自定义角色 员工账号/应用账号 使用产品特性 使用权限范围特性
1.2、默认账号
默认账号名称 角色 账号ID system SystemRole
0 admin AdminRole 1
1.3、账号体系映射
nacos 阿里云 内部 system
云产品账号 无 admin 主账号 无 员工账号，可多个 子账号（Ram 分配用户名密码） 员工账号 程序账号 子账号（Ram 分配 ak/sk） Dauth 分配账号及 ak/sk
2、身份识别
2.1、身份识别分类
账号类型 ⽤途 身份识别 用户账号 用于分配人管理资源 用户名/密码 应用账号 用于分配程序访问资源 ak/sk
2.2、账号区别
应用账号与应用负责人能用⼀个账号吗？不可以，因为人会流动，权限变动比较大。 因此⼀个应用的权限和应用开发负责*限是分开的， 用不同的账号。 应用有开发，测试，owner，其实他们有对应应用使用资源的不同权限。因此应用 负责人与应用的权限也不对等，不能共用⼀个账号。
????微服务实战
✨【微服务】SpringCloud的OpenFeign与Ribbon配置
✨Spring Cloud Alibaba微服务第29章之Rancher
✨Spring Cloud Alibaba微服务第27章之Jenkins
✨Spring Cloud Alibaba微服务第24章之Docker部署
✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式
✨Spring Cloud Alibaba微服务第22章之Oauth2
✨Spring Cloud Alibaba微服务第21章之分布式事务
✨Spring Cloud Alibaba微服务第18章之消息服务
✨Spring Cloud Alibaba微服务第16章之服务容错
✨Spring Cloud Alibaba微服务第14章之分库分表
✨Spring Cloud Alibaba微服务第11章之MyBatis-plus
✨Spring Cloud Alibaba微服务第8章之OpenFeign
✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon
✨SpringCloud Alibaba微服务第6章之Gateway
???? Spring家族及微服务系列文章
✨【微服务】SpringCloud中OpenFeign请求处理及负载均衡流程
✨【微服务】SpringCloud中Ribbon的WeightedResponseTimeRule策略
✨【微服务】SpringCloud中Ribbon的轮询(RoundRobinRule)与重试(RetryRule)策略
✨【微服务】SpringCloud中Ribbon集成Eureka实现负载均衡
✨【微服务】SpringCloud轮询拉取注册表及服务发现源码解析
✨【微服务】Nacos2.x服务发现？RPC调用？重试机制？
✨【微服务】SpringBoot监听器机制以及在Nacos中的应用
✨【微服务】SpringCloud中使用Ribbon实现负载均衡的原理
✨【微服务】SpringBoot启动流程注册FeignClient