之前我们知道kubernetes的授权是用插件来实现，并且支持很多插件，并且支持很多插件同时使用，且只要通过其中一个授权检查通过则不会在进行其他插件进行检查，而后由准入控制插件后续检查。
授权插件常用有四个：节点Node，ABAC属性访问控制，RBAC，Webhook回掉机制实现授权、
RBAC
RBAC的全称是Role-based AC，在kubernetes中RBAC就是定义标准的资源：
- Role:
operations(许可授权，在其中只要包含在内的写入的都是允许的，不能定义拒绝权限，因为没有就是拒绝权限),objects,
- rolebinding（角色绑定）
将用户(useraccount)或者serviceaccount绑定到那个角色上，让用户扮演那个角色
其中role和rolebinding有两个级别
在kubernetes中资源分属两种级别，集群和名称空间，role和rolebinding是名称空间级别内的许可权限。
基于角色的访问控制，用户作为访问的独立账号，角色(role)是授权机制：授权和许可(permission)
user扮演了角色1就拥有了角色1的权限，所有的授权都添加在角色上，用户扮演的 角色就拥有了角色权限
权限：对于对象，每一个被访问的组件都是对象，在restful 的api当中一切届对象，k8s上运行的组件分为三类， 对象占用了绝大部分，对象列表API，非对象资源，URL。在restful风格中的操作都是指在某个对象施加的(action)某种行为，称之operations。在一个对象上施加过程组合起来称为permissions. 而后可以在role上，授权于role拥有某个许可的权限(permissions)(在某些对象上实现某些操作的权限)。
如果需要使用基于角色访问控制，应该有user,role，permissions，而permissions就需要事先有一些objects，这些objects支持一些operations，这组合在一起就定义成了permissions。授于role，就完成了授权。
能够扮演角色并施加权限的有两个账号，如下：
userAccount和serviceAccount,serviceAccount，这些restful 接口执行类似与GET,PUT等操作，操作对象于位于url路径的对象列表或者一个具体的URL对象。把图一和图二绑定起来permissions，而后授予到角色上，让用户扮演角色，最后完成授权。
除开role和rol ebinding之外，还有两个组件clusterrole，clusetrrolebinding
在名称空间A中定义了角色(role)，角色和user1建立绑定关系(rolebinding)，user1就有了定义的角色(role)权限。user1的这些权限只能在当前名称空间下的所有pod生效。如下：
如果此时user1用户定义的是clusterRole，操作对象还是pod。user1用户和clusterRole建立绑定关系(也就是clusterRoleBinding)，那就会突破名称空间的边界，而是集群级别的权限，生效的范围在整个集群。如下：
那么如果名称空间b中的user1的rolebingding绑定集群级别的ClusterRole(角色)，而不是绑定namespace中的role(角色)，即便如此。权限仍然在namespace中，因为user使用rolebinding绑定的clusterRole，对用户来讲权限就限制在namespace中。这样以来clusterrole权限降级到rolebinding所有权限。如果要对某一个或几个名称空间做用户权限则可以如此。如下：
- role定义的在那个名称空间，生效范围在那个名称空间
