面向用户的内建ClusterRole
API Server 内建了一组默认的ClusterRole 和 ClusterRoleBinding 以预留系统使用，其中大多数都以 “system:” 为前缀。另外还有一些非以”system:”为前缀的默认的Role资源，他们是为面向用户的需求而设计，包括超级用户角色（cluster-admin)、用于授权集群级别资源的ClusterRoleBinding(cluster-status)以及赋予特定名称空间级别权限的RoleBinding(admin、edit、view)。掌握这些默认的内建ClusterRole对后期按需创建用户并快速配置权限至关重要。
内建的面向用户的内建ClusterRole资源
| 默认的ClusterRole | 默认的ClusterRolebinding | 说明 |
|---|---|---|
| cluster-admin | system:masters 组 | 赋予超级管理员在任何对象上执行任何操作的权限 |
| admin | None | 以Rolebinding 机制访问指定名称空间的所有资源，包括名称空间的role和rolebinding，但不包括资源配置和名称空间本身 |
| edit | None | 允许读写访问一个名称空间内的绝大多数资源，但不允许查看或修改Role或Rolebinding |
| view | None | 允许读取一个名称空间内的绝大多数资源，但不允许查看Role和RoleBinding，以及secret资源 |
其它内建ClusterRole和ClusterRoleBinding
API Server会创建一组默认的 ClusterRole 和 ClusterRoleBinding ,大多数都以 “system:” 开头，被系统基础架构使用，修改这些资源会导致集群功能不正常，或无法自愈. 例：如果修改了 kubelet赋权的 “system:node” 这一ClusterRole，则将会导致kubelet无法工作。所有默认的 ClusterRole 和 ClusterroleBinding 都会打了标签 “kubernetes.io/bootstrapping=rbac-defaults” 。 每次，启动时，API Server都会自动为默认ClusterRole 重新语序缺失的权限，以及为默认的 ClusterRoleBinding 绑定缺失的 Subject。 这种机制给了集群意外修改中自动恢复的能力，以及升级版本后，自动将ClusterRole和ClusterRoleBinding 升级到满足新版本需求的能力。
必要时，在默认的 ClusterRole或ClusterRoleBinding上设置annotation中"rbac.authorization.kubernetes.io/autoupdate" 属性的值为“false” 可以禁用这种自动恢复功能。
其他内建的ClusterRole和ClusterRoleBinding
- system:kube-sheduler
- system:kube-controller-manager
- system:node
- system:node-proxier
- system:kube-dns
