k8s 内置cluster role（集群角色） cluster-admin、admin、 edit、 view的作用范围及区别

• cluster-admin 超级管理员，对集群所有权限,和linux下面root一样（在部署dashboard的时候，先创建sa，然后将sa绑定到角色cluster-admin，最后获取到token，这就使用了内置的cluster-admin ）

• admin 主要用于授权命名空间所有读写权限(针对于某个命名空间)

• edit 允许对命名空间大多数对象读写操作，不允许查看或者修改角色、角色绑定。

• view 允许对命名空间大多数对象只读权限，不允许查看角色、角色绑定和Secret

• view ClusterRole 允许对资源的只读访问
  在前面的例子中， 我们已经使用了默认的view ClusterRole。 它允许读取 一个 命名空间中的大多数资源， 除了Role、 RoleBinding和 Secret。 你可能会想为什么Secrets不能被读取？因为Secrets中的某一个可能包含一个认证token，它比定义在view ClusterRole中的资源有更大的权限 ， 并且允许用户伪装成不同的用户来获取 额外的权限（权限扩散）。

• edit ClusterRole允许对资源的修改
  接下来是edit ClusterRole, 它允许你修改一 个命名空间中的资源，同时允许读取和修改Secret。
  但是， 它也不允许查看或修改Role和 RoleBinding, 这是为了防止权限扩散。

• admin ClusterRole赋予一个命名空间全部的控制权
  一 个命名空间中的资源的完全控制权是由admin ClusterRole赋予的。 有这个ClusterRole的主体可以读取和修改命名空间中的任何资源， 除了ResourceQuota 和命名空间资源本身。 edit和admin ClusterRole 之间的主要区别是能否在命名空间中查看和修改Role和RoleBinding。
  注意为了防止权限扩散， API服务器只允许用户在已经拥有一个角色中列出的所有权限（以及相同范围内的所有权限）的 情 况下， 创建和更新这个角色 。

• 用cluster-admin ClusterRole得到完全的控制

  通过将cluster-admin ClusterRole赋给主体， 主体可以获得Kubernetes 集群完全控制的权限。 正如你前面了解的那样， adminClusterRole不允许用户修改命名空间的 ResourceQuota对象或者命名空间资源本身。
  如果你想允许用户这样做， 需要创建一 个指向cluster-adminClusterRole的 RoleBinding。 这使得RoleBinding 中包含的用户 能够完全控制创建RoleBinding所在命名空间上的所有方面 。
  如果你留心观察， 可能已经知道如何授予用户一个集群中所有命名空间的完全控制权 。 就是通过在ClusterRoleBinding而不是RoleBinding中引用cluster admin ClusterRole。
  内置角色是可以直接使用的，这样方便授权。

参考链接：
https://blog.csdn.net/qq_34556414/article/details/119413202