访问控制模型

控制访问模型有哪几种？我们需要先来了解下这个。

UGO(User, Group, Other)

这个是 Linux 中对于资源进行权限管理的访问模型。Linux 中一切资源都是文件，每个文件都可以设置三种角色的访问权限（文件创建者，文件创建者所在组，其他人）。这种访问模型的缺点很明显，只能为一类用户设置权限，如果这类用户中有特殊的人，那么它无能为力了。

ACL(访问控制列表)

它的原理是，每个资源都配置有一个列表，这个列表记录哪些用户可以对这项资源进行 CRUD 操作。当系统试图访问这项资源的时候，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定这个用户是否有权限访问当前资源。linux 在 UGO 之外，也增加了这个功能。

setfacl -m user:yejianfeng:rw- ./test

[yejianfeng@ipd-itstool ~]$ getfacl test

# file: test

# owner: yejianfeng

# group: yejianfeng

user::rw-

user:yejianfeng:rw-

group::rw-

mask::rw-

other::r--

当我们使用 getfacl 和 setfacl 命令的时候我们就能对某个资源设置增加某个人，某个组的权限列表。操作系统会根据这个权限列表进行判断，当前用户是否有权限操作这个资源。

（*）RBAC(基于角色的权限访问控制)

这个是很多业务系统最通用的权限访问控制系统。它的特点是在用户和具体权限之间增加了一个角色。就是先设置一个角色，比如管理员，然后将用户关联某个角色中，再将角色设置某个权限。用户和角色是多对多关系，角色和权限是多对多关系。所以一个用户是否有某个权限，根据用户属于哪些角色，再根据角色是否拥有某个权限来判断这个用户是否有某个权限。

RBAC 的逻辑有更多的变种。

变种一：角色引入继承

角色引入了继承概念，那么继承的角色有了上下级或者等级关系。

变种二：角色引入了约束

角色引入了约束概念。约束概念有两种，

一种是静态职责分离：

a、互斥角色：同一个用户在两个互斥角色中只能选择一个

b、基数约束：一个用户拥有的角色是有限的，一个角色拥有的许可也是有限的

c、先决条件约束：用户想要获得高级角色，首先必须拥有低级角色

一种是动态职责分离：

可以动态的约束用户拥有的角色，如一个用户可以拥有两个角色，但是运行时只能激活一个角色。

变种三：既有角色约束，又有角色继承

就是前面两种角色变种的集合。

ABAC(基于属性的权限验证)

Attribute-based access control，这种权限验证模式是用属性来标记资源权限的。比如 k8s 中就用到这个权限验证方法。比如某个资源有 pod 属性，有命名空间属性，那么我设置的时候可以这样设置：

Bob 可以在命名空间 projectCaribou 中读取 pod：

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}

这个权限验证模型的好处就是扩展性好，一旦要增加某种权限，就可以直接增加某种属性。

DAC（自主访问控制）

在 ACL 的访问控制模式下，有个问题，能给资源增加访问控制的是谁，这里就有几种办法，比如增加一个 super user，这个超级管理员来做统一的操作。还有一种办法，有某个权限的用户来负责给其他用户分配权限。这个就叫做自主访问控制。

比如我们常用的 windows 就是用这么一种方法。

很多的 wiki 权限也是这样的权限管理方式。

MAC(强制访问控制)

强制访问控制和 DAC 相反，它不将某些权限下放给用户，而是在更高维度（比如操作系统）上将所有的用户设置某些策略，这些策略是需要所有用户强制执行的。这种访问控制也是基于某些安全因素考虑。