RBAC 插件介绍

在 RBAC 插件的使用过程中，它总共使用四种资源来实现 用户主体 对 API 服务器提供的 URL 路径的访问控制：

• 角色 : Role 资源和 ClusterRole 资源；角色 用来限制针对哪些 URL 路径可以执行哪些操作；

• 角色绑定 : RoleBinding 资源和 ClusterRoleBinding 资源；角色绑定 用来将 角色 与 用户主体 进行绑定，从而规定该 用户 或 ServiceAccount 或 组 可以完成的操作；

🚦 RBAC 插件是以 URL 路径为限制粒度的。

因为 API 服务器为 用户主体 提供了 HTTP 接口以供调用，Kubernetes 中每个资源对象均有其唯一的 URL 路径，但是 Kubernetes 集群中不仅提供了资源对象的 URL 路径，还包括一些非资源类型，比如用来检测资源对象是否健康的 /healthz 路径等。所以在此处理解为 角色 是用来限制针对哪些 URL 路径可以执行哪些操作更为准确。

Role 和 ClusterRole 或者 RoleBinding 和 ClusterRoleBinding 之间的区别在于，前者是命名空间中的资源，而后者则是集群级别的资源

角色与角色绑定的关系

先用 角色 定义权限，即能针对哪些 URL 路径执行哪些操作；

然后将 角色绑定 与 用户主体 进行绑定，用户主体 包括：用户、ServiceAccount 以及 组；

可限制操作

上述提到，角色 是用来限制可以针对哪些 URL 路径执行哪些操作的，这里将介绍一下可以限制的操作类型（在 角色 资源中被称为 verb，即动词），以及这些操作对应的 HTTP 方法（因为调用 API 服务器本质上就是用 HTTP 请求调用的）。

RBAC 插件不仅可以针对某个资源对象 URL 路径进行限制，还可以针对所有资源类型 URL 路径以及非资源类型 URL 路径进行限制，角色 中可以使用的动词以及对应的 HTTP 方法如下表所示：

HTTP方法	操作单个资源的动词（比如获得指定的 Service 对象）	操作批量资源的动词（比如操作所有 Service 对象）
GET, HEAD	get (以及 watch 用于监听)	list (以及 watch 用于监听)
POST	create	无
PUT	update	无
PATCH	patch	无
DELETE	delete	deletecollection
	use

🏵 use 这个动词是针对 PodSecurityPolicy 资源的

四种资源的组合

⚠️ 注意，这四种组合并不只有 Role <-> RoleBinding 以及 ClusterRole <-> ClusterRoleBinding 两种组合方式，还有一种 ClusterRole <-> RoleBinding 方式，不同的组合方式有不同的限制效果。

🚧 在之前的介绍中，我们知道 角色 是用来限制 URL 路径和对应操作的，其中 Role 仅能限制其所在命名空间中的资源型 URL 和对应操作，ClusterRole 则可以限制集群级别的 URL 路径（包括集群级别资源 URL 以及非资源型 URL）和对应操作。但是，限制操作资源的还有 绑定，若使用了 ClusterRole <-> RoleBinding 的组合方式，则即使 ClusterRole 的定义可以访问其他命名空间中的资源 URL，但是由于 RoleBinding 是属于某个命名空间中的，因此其绑定的 用户主体 还是只能够操作本命名空间中的资源 URL。

下面总结一下各组合的使用场景：

访问的 URL 路径	角色	角色绑定
集群级别的资源 URL (Nodes、PV...)	ClusterRole	ClusterRoleBinding
非资源型 URL (/api、/healthz...)	ClusterRole	ClusterRoleBinding
任何命名空间中的资源 URL（和跨所有命名空间的资源）	ClusterRole	ClusterRoleBinding
在具体命名空间中的资源 URL（可在不同命名空间中创建 RoleBinding 与该 ClusterRole 绑定以供本地或其他命名空间中的用户主体访问 RoleBinding 所在命名空间中的资源 URL）	ClusterRole	RoleBinding
在具体命名空间中的资源 URL（可在不同命名空间中创建 RoleBinding 与本地 Role 绑定，以供本地或其他命名空间中的用户主体访问 RoleBinding 所在命名空间资源）	Role	RoleBinding

从最后两个场景中可以看出，RoleBinding 会限制访问的资源 URL 所在的命名空间，即使使用的是 ClusterRole；

虽然最后两个场景的访问效果是一致的，但是倒数第二种仅需要创建一次 角色 资源就可以重复使用，不用每次都重复创建；

‼️ ‼️ ‼️ 再次强调！若创建了一个 ClusterRoleBinding 并绑定了 ClusterRole，则用户主体可以操作所有命名空间的 URL 路径；但是若创建的是 RoleBinding 并绑定了ClusterRole，那么用户主体只能操作 RoleBinding 所在命名空间的 URL 路径；

集群级别资源 URL ：在 Kubernetes 集群中，并不是所有的资源都有其所属的命名空间的，比如 Node、PersistentVolume、Namespace 等等，这类资源就属于 集群级别资源，只能使用 ClusterRole 去限制对它们的操作；

非资源型 URL ：Kubernetes 集群中每种资源都有对应的 URL，我们可以通过访问对应 URL 来查看、更新、删除对应资源对象，但是它也具有一些非资源的 URL，比如用来检测对象是否健康的 /healthz URL，或者是 /api 、/apis 等等，它们都是非资源型的 URL，只能使用 ClusterRole 去限制对它们的操作；