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
