Kubernetes的授权是基于插件形式的，其常用的授权插件有以下几种：

    • Node（节点认证）
    • ABAC(基于属性的访问控制)
    • RBAC（基于角色的访问控制）
    • Webhook（基于http回调机制的访问控制）

    image.png

    让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制

    基于角色的访问控制（Role-Based Access Control，即 RBAC）使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略

    在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是 把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限

    此种方式仅作用于名称空间当中，这是什么意思呢？
    当User1绑定到Role角色当中，User1就获取了对该NamespaceA的操作权限，但是对NamespaceB是没有权限进行操作的，如get，list等操作

    另外，k8s为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将User2，User3通过ClusterRoleBinding到ClusterRole，从而使User2、User3拥有集群的操作权限

    这里有2种绑定ClusterRoleBinding、RoleBinding，也可以使用RoleBinding去绑定ClusterRole

    当使用这种方式进行绑定时，用户仅能获取当前名称空间的所有权限，为什么这么绕呢？
    举例有10个名称空间，每个名称空间都需要一个管理员，而该管理员的权限都是一致的，那么此时需要去定义这样的管理员，使用RoleBinding就需要创建10个Role，这样显得更加繁重，为此当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操作权限，换句话说，此时只需要创建一个ClusterRole就解决了以上的需求

    PS：RoleBinding仅仅对当前名称空间有对应的权限

    相关文档：https://www.cnblogs.com/wlbl/p/10694364.html