目录
一、背景
1、账号体系
2、账号实体映射
二、方案
1、Nacos 资源模型
2、Nacos 授权 resource
2.1、授权 resource 组成
2.2、不同级别授权资源组成
3、Nacos 授权 Opers
4、Nacos 具体权限定义
4.1、Opers 组成
4.2、具体实例
4.3、工程实现
三、RBAC 设计实现
1、RBAC 账号权限组成
1.1、角色
1.2、默认账号
1.3、账号体系映射
2、身份识别
2.1、身份识别分类
2.2、账号区别
💖微服务实战
💖 Spring家族及微服务系列文章
一、背景
为了 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配置
✨集Oauth2+Jwt实现单点登录
✨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
✨SpringCloud Alibaba微服务第4章之Nacos
✨SpringCloud Alibaba微服务开篇
💖 Spring家族及微服务系列文章
✨【Spring】一文带你吃透IOC容器技术
✨【微服务】SpringCloud中OpenFeign请求处理及负载均衡流程
✨【微服务】SpringCloud中Ribbon的WeightedResponseTimeRule策略
✨【微服务】SpringCloud中Ribbon的轮询(RoundRobinRule)与重试(RetryRule)策略
✨【微服务】SpringCloud中Ribbon集成Eureka实现负载均衡
✨【微服务】SpringCloud轮询拉取注册表及服务发现源码解析
✨【微服务】SpringCloud微服务续约源码解析
✨【微服务】SpringCloud微服务注册源码解析
✨【微服务】Nacos2.x服务发现？RPC调用？重试机制？
✨【微服务】Nacos通知客户端服务变更以及重试机制
✨【微服务】Nacos服务发现源码分析
✨【微服务】SpringBoot监听器机制以及在Nacos中的应用
✨【微服务】Nacos服务端完成微服务注册以及健康检查流程
✨【微服务】Nacos客户端微服务注册原理流程
✨【微服务】SpringCloud中使用Ribbon实现负载均衡的原理
✨【微服务】SpringBoot启动流程注册FeignClient
✨【微服务】SpringBoot启动流程初始化OpenFeign的入口
✨Spring Bean的生命周期
✨Spring事务原理
✨SpringBoot自动装配原理机制及过程
✨SpringBoot获取处理器流程
✨SpringBoot中处理器映射关系注册流程
✨Spring5.x中Bean初始化流程
✨Spring中Bean定义的注册流程
✨Spring的处理器映射器与适配器的架构设计
✨SpringMVC执行流程图解及源码
