k8s源码学习到用户认证这一部分，后续就是权限认证机制。所以先预先了解一下目前后端常见的一些认证机制以及他们的演变关系。

权限认证机制基本概念

针对不同的使用场景，我们可以使用不同的权限认证机制。

1. ACL 访问控制列表

通过访问控制表，限定资源可以被主体进行哪些操作。
举个例子：

资源： A
    主体： 用户甲
    允许的操作：增删改查
    主体： 用户乙
    允许的操作： 增
资源： B
    主体： 用户甲
    允许的操作： 删

在维护性上，一般在粗粒度和相对静态的情况下，比较容易维护。在细粒度情况下，比如将不同的客户视为不同的资源，1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的，那么就要对每种资源做相同的操作；如果权限配置是无规律的，那么ACL不妨也是一种恰当的解决方案。
在动态情况下，权限经常变动，每添加一名员工，都需要配置所有他需要访问的资源，这在频繁变动的大型系统里，也是很难维护的。
适用于规则简单，主体数量比较少的场景。

2. DAC 自主访问控制

规定资源可以被哪些主体进行哪些操作；同时，主体可以将资源、操作的权限，授予其他主体。

DAC是ACL的一种衍生，主体不光有普通的权限，还可以进行权限的扩展操作，传播权限。
适合一些需要进行授权的场景。

3. MAC 强制访问控制

有两点：
a. 规定资源可以被哪些类别的主体进行哪些操作
b. 规定主体可以对哪些等级的资源进行哪些操作

当一个操作，同时满足a与b时，允许操作。

相当于不只有权限的访问控制列表，还增加了一个主体信息的配置表。

举个例子：

资源配置表
        资源: 财务文档
                主体: 财务人员
                等级：机密级
                操作：查看
主体配置表

        主体: 李女士
                类别: 财务人员
                等级：机密级

一份机密级的财务档案，可以确保只有主体的等级是机密级，且是财务人员才能访问。如果是机密级的行政人员就无法访问。

MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。同时相比ACL，多了一层，配置更灵活。

4. RBAC 基于角色的访问控制

a. 规定角色可以对哪些资源进行哪些操作
b. 规定主体拥有哪些角色
当一个操作，同时满足a与b时，允许操作。

RABC并不总能满足所有权限的场景。比如，我们无法对角色，进行个体定制。比如，销售角色拥有创建、删除的权限。如果我们要对销售小李，去掉删除的权限。那么，我们就必须创建另一个角色，来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。所以如何维护角色，是好好使用RBAC的关键。

优点

• 稳定：从管理角度出发，角色是为了解决特定问题而被创造的，也就是解决分工问题，而用户的变动几率比系统里的角色大多了，角色这一定义相对会更加稳定一些。
• 简单：用户与权限的逻辑分离，使得权限只和角色相关。而根据上文，角色是被相关干系人或行业直接创造出来的，以角色为核心的权限管理体系的理解成本和学习成本相对于新造概念会少上很多，非常利于在内部推广。
  缺点
• 从管理角度出发，角色是为了解决特定问题而被创造的，也就是解决分工问题，而自然人的变动几率比系统里的角色大多了，角色这一定义相对会更加稳定一些。

5. ABAC 基于属性的访问控制

规定哪些属性的主体可以对哪些属性的资源在哪些属性的情况下进行哪些操作。
基于操作属性确定一个操作是否被允许；操作可以是删除、访问等等，属性需要预先定义：

• 对象：用户 ID、用户职位、部门、入职时间、是否通过试用期等等
• 资源：资源创建日期、资源最新更新时间、资源类型（文件、订单详情数据）、资源分类（订单管理、文章管理等）等
• 操作：新增、查看、删除等
• 环境：IP 地址、时间等

举一个简单的例子：

• 初级前端工程师（对象）可以下载（操作）内网中的（环境）GitLab 前端源代码（资源）

RBAC历史悠久，ABAC曾经被看做是未来使用最多的权限模型，但是目前来看，RBAC依旧能覆盖大部分的使用场景。

ABAC的优缺点主要在于：
优势:

• 颗粒度小：由于其基于属性组合确定权限的逻辑设计，ABAC 理论上能够实现非常小颗粒度的权限控制，同时也几乎能够满足所有需求；
• 灵活：非常适用于公司成员（角色）快速变化的时候，此时并不需要修改角色信息，只有修改一下对应账户的属性就能非常便捷地适配新的权限。

劣势：

• 策略定制比较麻烦，这点有些类似于 RBAC 的角色维护，但是两者在不同规模的公司里会有一些差异。在中小规模公司，角色的维护会比策略的定制更加方便，毕竟人数也不多。而对于大型公司，大型跨地区公司，大型跨国公司，由于人员、空间、时间等等各种问题，维护角色反而是比策略定制更加麻烦。
• 另外就是安全和统计问题，ABAC 是灵活的，但同时也是复杂的。我们很难说一个账户永远不能访问某项资源，除非我们了解资源相关的所有策略，因此在完整搭建起了复杂的 ABAC 权限系统后要确定一个账户是否完全没有某项资源的权限是比较困难的。
• 最后是性能，ABAC 的一系列优点都是建立在占用更多性能的前提下，而有些时候系统的响应速度和稳定性是相当重要的，如何在复杂的 ABAC 策略下，保持相对不错的性能和稳定性也是很重要的。

详细展开RBAC

RBAC模型（Role-Based Access Control：基于角色的访问控制）模型是20世纪90年代研究出来的一种新模型，但其实在20世纪70年代的多用户计算时期，这种思想就已经被提出来，直到20世纪90年代中后期，RBAC才在研究团体中得到一些重视，并先后提出了许多类型的RBAC模型。其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公认。

RBAC认为权限授权的过程可以抽象地概括为：Who是否可以对What进行How的访问操作，并对这个逻辑表达式进行判断是否为True的求解过程，也即是将权限问题转换为What、How的问题，Who、What、How构成了访问权限三元组.

RBAC模型里，有三种元素：用户、角色、权限。

RBAC模型的演变存在多个版本：

1. RBAC-0 模型

RBAC0是RBAC模型的核心基础思想，即用户通过被赋予角色和权限进行关联。用户、角色和权限之间的两两关系均是多对多关系，即一个用户可以被赋予多个角色，一个角色可以被赋予多个用户。一个角色可以拥有多项权限，一项权限可以赋予多个角色。

角色起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。

2. RBAC-1 模型

RBAC1是引入继承关系的RBAC模型，一个角色可以从另一个角色继承许可权，即角色具有上下级的关系.角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承，受限继承关系则进一步要求角色继承关系是一个树结构

3. RBAC-2 模型

RBAC-2模型在用户与角色间和角色与角色之间加入了一些规则。规定了权限被赋予角色时或角色被赋予用户时所应遵循的强制性规则。角色互斥、基数约束、先决条件角色等。

• 互斥角色：同一用户在两个互斥角色中只能选择一个，分为静态职责分离SSD和动态职责分离SSD
  先决条件角色 ：指要想获得较高的权限，要首先拥有低一级的权限。角色A为角色B的上级，要想为用户分配角色A，则必须先分配角色B
• 基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；一个角色的权限数目受限
• 运行时互斥：允许一个用户具有两个角色，但在运行中不可同时激活这两个角色。运行时只能激活一个角色