# RBAC default Roles and Role Bindings

参考文档:Using RBAC Authorization

API server 将创建一组默认的 ClusterRoleClusterRoleBinding 对象。其中许多都是以 system: 开头的,表明该对象属于系统层面。如果修改这些对象,将导致集群不可用。例如 system:node ClusterRole,定义了 kubelet 的权限。如果该 ClusterRole 被修改,可能使得 kubelet 不能正常工作。

所有的默认 Role 以及 RoleBinding 都带有标签 kubernetes.io/bootstrapping=rbac-defaults

# Auto-reconciliation

API Server 每次启动时,都会更新默认 ClusterRole 以补全可能缺失的权限,并且也会更新默认的 ClusterRoleBinding 以补全可能缺失的被授权主体。这样,集群可以自动修复意外的修改,同时可以使 Role 中的权限、RoleBinding 中的被授权主体与最新的 Kubernetes 版本保持一致(如果升级了 Kubernetes 的话)。

如果要禁用这个特性,将默认 ClusterRole 或 ClusterRoleBinding 上的注解 rbac.authorization.kubernetes.io/autoupdate 设置为 false 即可。

  • 请注意,如果缺失默认的权限,将导致集群不可用
  • Auto-reconciliation 自 Kubernetes 1.6 开始,随 RBAC 一起生效。

# Discovery Roles

默认 RoleBinding 授权匿名用户(和已登录用户)读取公开的 API 信息(包括 CustomResourceDefinitions)。如果要禁止匿名用户访问,可在 API Server 的启动参数里添加 --anonymous-auth=false

如需查看这些角色的配置,可执行如下命令:

kubectl get clusterroles system:discovery -o yaml
1

注意:不推荐编辑这些角色,因为 API Server 重启时,会被重新修改,参考 auto-reconciliation

Default ClusterRole Default ClusterRoleBinding 描述
system:basic-user system:authenticated group 授予用户对自己的信息的只读权限。在 1.14 之前,该角色也默认被绑定到 system:unauthenticated
system:discovery system:authenticated group 授予用户只读权限,读取用于发现及协商 API 等级的 API 发现端口。在 1.14 之前,该角色也默认被绑定到 system:unauthenticated
system:public-info-viewer system:authenticated and
system:unauthenticated groups
授予用户只读权限,读取集群的非敏感信息。自 1.14 开始引入。

# User-facing Roles

一部分默认 Role 没有 system: 前缀,这些是直接给用户使用的(user-facing),包括:

  • 超级用户的角色(cluster-admin
  • 可通过 ClusterRoleBinding 绑定的集群级别的角色(cluster-status
  • 可通过 RoleBinding 绑定到特定名称空间的角色(admineditview

从 Kubernetes 1.9 开始,user-facing roles 使用 ClusterRole Aggregation 以使管理员在其中包含 Custom Resource 的授权规则。向 admineditview 等角色添加授权规则时,可创建一个 ClusterRole,包含一个或多个下述标签即可:

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
1
2
3
4
5
Default ClusterRole Default ClusterRoleBinding Description
cluster-admin system:masters group 允许超级用户针对任意资源执行任意操作。如果绑定到 ClusterRoleBinding,将授予被授权主体针对集群中以及所有名称空间中任意资源的完全控制权。如果绑定到 RoleBinding,将授予被授权主体针对该名称空间下所有资源的完全控制权(包括名称空间本身)
admin None 授予管理员访问权限,可以被用来绑定到名称空间中的 RoleBinding。此时,允许对名称空间中大多数资源的 read/write 访问,包括在名称空间中创建 role 以及 rolebinding 的权限。但是不允许对 resource quota 或名称空间本身执行 write 操作。
edit None 授予名称空间中大多数资源的 read/write 权限。但是不能够查看或编辑 role 和 rolebinding
view None 授予名称空间中大多数资源的 read-only 权限。但是不允许查看 role 和 rolebinding,也不允许查看 secrets。

# Core Component Roles

Default ClusterRole Default ClusterRoleBinding Description
system:kube-scheduler system:kube-scheduler user 允许访问 kube-scheduler 组件所需要的资源
system:volume-scheduler system:kube-scheduler user 允许访问 kube-scheduler 组件所需要的数据卷资源
system:kube-controller-manager system:kube-controller-manager user 允许访问 kube-controller-manager 组件所需的资源。特定控制器所需的权限定义在 controller roles 当中
system:node None in 1.8+ 允许访问 kubelet 组件所需的资源,包括 读取所有的 secrets,写入所有的 pod status。在 kubernetes 1.7 中,推荐使用 Node authorizerNodeRestriction admission plugin,而不是这个 role,并且推荐为 kubelet 授予访问运行在其所在节点上的 Pod 的 API 权限。在 1.7 之前,此角色被自动绑定到 system:nodes group。在 1.7 中,如果 Node authorization 模式未启用,此角色被自动绑定到 system:nodes group。自 1.8 开始,将不会为其自动创建角色绑定
system:node-proxier system:kube-proxy user

# Other Component Roles

Default ClusterRole Default ClusterRoleBinding Description
system:auth-delegator None Allows delegated authentication and authorization checks. This is commonly used by add-on API servers for unified authentication and authorization.
system:heapster None Role for the Heapster component.
system:kube-aggregator None Role for the kube-aggregator component.
system:kube-dns kube-dns service account in the kube-system namespace Role for the kube-dns component.
system:kubelet-api-admin None 允许访问所有的 kubelet API.
system:node-bootstrapper None 允许访问执行 Kubelet TLS bootstrapping 时所需要的资源
system:node-problem-detector None Role for the node-problem-detector component.
system:persistent-volume-provisioner None 允许访问大多数 dynamic volume provisioners 所需要的资源

# Controller Roles

Kubernetes controller manager 中包含了核心的控制器。如果其启动参数中添加了 --use-service-account-credentials,每一个控制器在启动时都将使用单独的 service account,并绑定到对应的角色(以system:controller 为前缀)。如果 Kubernetes controller manager 启动是不带参数 --use-service-account-credentials,则所有的控制器都使用其自身的身份标识,此时,必须为其绑定所有的相关角色。这些角色包括:

  • system:controller:attachdetach-controller
  • system:controller:certificate-controller
  • system:controller:clusterrole-aggregation-controller
  • system:controller:cronjob-controller
  • system:controller:daemon-set-controller
  • system:controller:deployment-controller
  • system:controller:disruption-controller
  • system:controller:endpoint-controller
  • system:controller:expand-controller
  • system:controller:generic-garbage-collector
  • system:controller:horizontal-pod-autoscaler
  • system:controller:job-controller
  • system:controller:namespace-controller
  • system:controller:node-controller
  • system:controller:persistent-volume-binder
  • system:controller:pod-garbage-collector
  • system:controller:pv-protection-controller
  • system:controller:pvc-protection-controller
  • system:controller:replicaset-controller
  • system:controller:replication-controller
  • system:controller:resourcequota-controller
  • system:controller:root-ca-cert-publisher
  • system:controller:route-controller
  • system:controller:service-account-controller
  • system:controller:service-controller
  • system:controller:statefulset-controller
  • system:controller:ttl-controller