RBAC（Role-Based Access Control，基于角色的访问控制）在Kubernetes v1.5引入，在v1.6版本时升级为Beta版本，并成为kubeadm安装方式下的默认选项，组建其重要程度。相对于其他的访问控制方式，RBAC具有如下优势。

• 对集群中的资源和非资源权限均有完整的覆盖。
• 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作。
• 可以在运行时进行调整，无须重新启动API Server。

要使用RBAC授权模式，则需要在API Server的启动参数中加上--authorization-mode=RBAC。

下面对RBAC的原理和用法进行说明。

1. RBAC的API资源对象说明

RBAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding。同其他API资源对象一样，用户可以使用kubectl或者API调用方式操作这些资源对象。

角色（Role）
一个角色就是一组权限的集合，这里的权限都是许可形式，不存在拒绝的规则。在一个命名空间中，可以用Role来定义一个角色，如果是集群级别，就需要使用ClusterRole了。
Role只能对命名空间内的资源进行授权，下面例子中定义的角色具备读取Pod的权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace： default
  name: pod-reader
rules:
  - apiGroups: [""] # ""空字符串，表示核心API群
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

rules中的参数说明：

• apiGroups： 支持的API组列表，例如“apiVersion: batch/v1”、“apiVersion: extensions:v1beta1”、“apiVersion: apps/v1beta1”等。
• resources：支持的资源对象列表，例如pods、deployments、jobs等。
• verbs：对资源对象的操作方法列表，例如get、watch、list、delete、replace、patch等。

集群角色
集群角色处理具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。

• 集群范围的资源，例如Node（节点）。
• 非资源类型的路径，例如“/healthz”。
• 包含全部命名空间的资源，例如pods（用于kubectl get pods --all-namespaces这样的操作授权）。
  下面的ClusterRole可以让用户有权访问任意一个或所有命名空间的secrets（视其绑定方式而定）：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # ClusterRole不受限于命名空间，所以省略了namespace name的定义
  name: secret-reader
rules:
  - apiGroups: [""] # ""空字符串，表示核心API群
    resources: ["secrets"]
    verbs: ["get", "watch", "list"]

角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）
RoleBinding或ClusterRoleBinding用来把一个角色绑定到一个目标上，绑定的目标可以是User（用户）、Group（组）或者Service Account。
使用RoleBinding为某个命名空间授权，使用ClusterRoleBinding为集群范围内授权。
RoleBinding可以引用Role进行授权。下面例子中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane，这一操作让jane可以读取default命名空间中的Pod：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding也可以引用ClusterRole，对属于同一个命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组角色（ClusterRole），然后在多个命名空间中重复使用这些ClusterRole。

例如下面的例子，虽然secret-reader是一个集群角色，但是因为使用了RoleBinding，所以dave只能读取development命名空间中的secret：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: development
  name: read-secret
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许manager组的用户读取任意namespace中的secret：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: development
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io