Kubernetes认证、授权与准入控制

一、Kubernetes的访问控制体系

API Server是Kubernetes集群的网关，是能够与etcd通信的唯一入口。因此，确保对API Server的安全访问至关重要。API Server会对每一次的访问请求进行合法性校验，包括用户身份验证、操作权限验证等。确认无误后才能访问或将数据存入到etcd中。
      API Server内置了一个三级别的访问控制机制：

• 认证：判断请求用户是否为合法用户。若为非法用户，则API Server返回401状态码并终止该请求。若为合法用户，则进入访问控制的第二阶段。
• 鉴权：API Server判断用户是否有权限进行请求中的操作。若无权进行操作，则返回403状态码，并终止该请求。若为合法用户，则进入访问控制的第三阶段。
• 准入控制：判断请求是否安全合规。如果最终验证通过的话，访问控制流程才会结束。

总结：请求到达API Server在完成身份认证、鉴权认证与准入控制认证后才可执行操作。

这三个机制都是以插件化的形式在工作，每种访问控制机制都有一组专用的插件栈。

• 认证：身份检验过程遵循”或”逻辑，任何一个插件检验成功后就不再进行后续的插件验证。但如果所有插件都检验不成功，则失败，或以“匿名者”身份访问。最好禁用”匿名者”。
• 鉴权：鉴权过程遵循”或”逻辑，任何一个插件对操作有许可授权后就不再进行后续的插件验证。但当无插件提供许可授权时，则拒绝请求的操作。
• 准入控制：内容合规性检查过程遵循”与”逻辑，无论成败，每次的操作请求都要经过所有插件的检验。

• 在数据写入etcd前负责检查内容的有效性，因此仅对”写”操作有效。原因就是一次性报告所有可能识别的错误状态给用户。
• 分为两类：validating(校验)和mutating(补全或订正)

二、API身份验证

2.1 用户类型介绍

“用户”即服务请求者的身份指代，一般使用身份标识符进行识别。可分为用户标识(用户名或ID)和用户组(把用户划分为若干的逻辑组)。
      Kubernetes系统的用户大体分为两类：

• Service Account：服务账户，其主体是”应用程序”，专用于为Pod资源中的服务进程提供访问Kubernetes API的身份标识。

• API Server使用ServiceAccount类型的资源对象来保存此类账号。隶属名称空间级别。

• User Account：用户账户，指非Pod类的客户端访问API Server时使用的身份标识，一般为现实中的”人”。

• API Server没有为这类账户提供保存其信息的资源类型(即不能实例化，无法保存到etcd)，相关信息通常保存于外部的文件或认证系统中。
• 身份核验操作可由API Server进行，也可由外部身份认证服务完成
• 本身并不是由Kubernetes管理，因而作用域为整个集群级别

2.2 身份认证策略

• X509证书认证

相对应用较多的使用方式，访问者会使用由集群CA(Certificate Authority，证书签发机构) 签发的，或是授信 CA 签发的客户端证书去访问 API Server。是 Kubernetes 组件之间默认使用的认证方式，也是kube-config 中经常使用到的访问凭证。kubeadm部署的Kubernetes集群默认使用/etc/kubernetes/pki/ca.crt进行客户端认证。

• 持有者令牌(Bearer Tokens)

• 静态令牌文件(Static Token File)认证：即保存用于认证的令牌信息的静态文件，由kube-apiserver的命令行选项--token-auth-file加载，且API Server进程启动后不可更改。
• 引导令牌(Bootstrap Token)认证：一种动态管理持有者令牌进行身份认证的方式，常用于组件新的Kubernetes集群时将节点加入集群的认证过程，由kube-apiserver通过--experimental-bootstrap-token-auth选项启用。新的工作节点首次加入时，Master使用引导令牌确认节点身份的合法性之后自动为其签署数字证书以用于后续的安全通信，kubeadm初始化集群也是用这种认证方式。这些令牌作为Secrets存储在kube-system命名空间中，可动态管理和创建。
• ServiceAccount令牌认证：该认证方式由kube-apiserver自动启用，它同样使用签名的持有者令牌来验证请求。
• OpenID Connect(OIDC)令牌认证：是OAuth 2协议的扩展，简单理解为API Server将认证需求委托给第三方.
• Webhook令牌认证：将请求的 Token 发送到指定外部服务进行 Token 的验签。

• 身份认证代理：将身份认证功能基于代理服务转交出去。

注意：令牌简单的可以理解为一个密码串。

2.3 API Server启动的身份认证机制

kubeadm部署的Kubernetes集群的API Server以静态Pod(即通过某个资源配置文件加载的Pod)形式运行，在配置文件/etc/kubernetes/manifests/kube-apiserver.yaml中，如下图绿框部分为kubeadm v1.27.1部署的集群默认启用的认证机制，由上到下依次为x509数字证书认证、Bootstrap令牌认证、身份认证代理、Service Account认证。
      注意：API Server并不保证各认证插件的生效次序与定义的次序相同。即定义靠前并不一定先发挥作用。

2.4 kubelet启动的身份认证机制

在Node节点的/var/lib/kubelet/config.yaml中，如下图绿框部分为kubelet启用的认证机制，自上而下分别为webhook和x509客户端证书认证。

注意：建议显式指定禁用匿名用户

三、认证功能介绍

3.1 静态令牌认证

API Server的静态令牌认证文件遵循CSV格式，每一行存储一个用户账户信息，由“令牌、用户名、用户ID和所属的用户组”四个字段组成，用户组为可选字段。由kube-apiserver启动时通过--token-auth-file选项加载。加载完成后的文件变动，仅能通过重启程序进行重载，因此相关的令牌会长期有效。客户端在HTTP请求中，通过“Authorization:Bearer TOKEN”标头附带令牌以完成认证。
      格式为password,user,uid,”group1,group2,group3”
      这里先普及一个概念，API Server上的每个资源对象，都在RESTful API中有一个端点。
      v1(核心资源群组)版本号的格式：https://API_SERVER:HOST/api/v1/namespaces/<NS_NAME>/<RESOURCE_NAME>/[<OBJECT_NAME>]
      比如default名称空间下的mypod的Pod资源，URL路径直接访问：

curl https://API_SERVER:HOST/api/v1/namespaces/default/pods/mypod

      其它群组的格式：https://API_SERVER:HOST/apis/GROUP_NAME/VERSION/namespaces/<NS_NAME>/<RESOURCE_NAME>/[<OBJECT_NAME>]
      客户端认证时，直接在HTTP中以Authorization:Bearer <token>标头完成认证。

#在Master节点的/etc/kubernetes目录下新建目录，在该目录下创建一个.csv文件，生成相关的用户配置。该令牌的第一部分为令牌ID，第二部分为令牌密钥
mkdir auth && cd auth
echo "`openssl rand -hex 3`.`openssl rand -hex 8`,tom,1001,kubeusers" >> /etc/kubernetes/auth/token.csv
chmod 400 /etc/kubernetes/auth/token.csv
#编辑/etc/kubernetes/manifests/kube-apiserver.yaml，添加配置选项--token-auth-file= /etc/kubernetes/auth/token.csv，同时添加挂载卷配置
spec:
  containers:
  - command:
    - kube-apiserver
    - --token-auth-file=/etc/kubernetes/auth/token.csv
……
volumeMounts:  #为容器指定额外的挂载的hostPath存储卷，存储有静态令牌文件
……
- mountPath: /etc/kubernetes/auth
  name: token-auth-files
  readOnly: true
volumes:
……
- hostPath:  #将宿主机上存储有静态令牌文件的目录作为hostPath存储卷
    path: /etc/kubernetes/auth
    type: DirectoryOrCreate
  name: token-auth-files

#测试
curl -k -H "Authorization:Bearer a993cf.89d6c2dbecede638" https://192.168.131.11:6443

此时返回403代码，说明tom用户无权进行相关请求操作(鉴权不通过)，但是认证却是通过了。如果未指定用户身份并以curl命令向Master节点的6443端口上HTTPS服务的根路径发起请求测试，会被识别为匿名用户，认证不通过。

3.2 X509数字证书认证

API Server是Kubernetes集群的通信网关，controller-manager、scheduler、kubelet及kube-proxy等API Server的客户端均需要经由API Server与etcd通信，完成资源状态信息的查询和更新等。出于安全通信的目的，Master端的各组件需要基于SSL/TLS向外提供服务，而且与集群内部组件间通信时(Node节点的kubelet和kube-proxy)还需要进行双向身份验证(服务端和客户端互相验证)。

在双向TLS通信中，客户端持有数字证书，而API Server信任客户端证书的颁发者。在API Server启动时，通过--client-ca-file选项指明信任的CA。认证通过后，客户端数字证书的CN(Common Name)被识别为用户名，而O(Organization)被识别为组名。

kubeadm部署Kubernetes集群时会自动生成所需要的证书，它们位于/etc/kubernetes/pki目录下。

Kubernetes集群内存在3个需要独立完成x509数字证书认证和HTTPS通信的体系：

• etcd集群成员、服务器及客户端Kubernetes的API Server将集群的状态数据存储到集群存储服务etcd中，包括含有敏感信息的Secret资源对象。Kubernetes集群各组件中，kube-apiserver是唯一一个可直接与集群存储通信的组件，它是etcd服务的客户端。
• API Server及其客户端，以及kubelet API及其客户端Kubernetes集群的各组件均需要API Server访问集群资源。同样出于安全性等目的，API Server也要借助HTTPS协议与客户端通信，x509双向数字证书认证仅是API Server支持的认证方式之一。客户端也可使用Bearer Token方式接入到API Server。
• Kubernetes认证代理体系中的服务器和客户端API Server支持将认证功能交由外部的其它服务代为完成，这些服务通过特定的响应头部返回身份验证的结果。API Server扩展服务就是认证代理的最常见应用场景之一。

      下表介绍了Kubernetes集群中用到的CA，证书路径基于/etc/kubernetes/pki目录下。

表1 Kubernetes 系统中的CA

完整运行的Kubernetes系统需要为etcd、API Server及前端代理(front proxy)生成多个数字证书，见下表。

表2 Kubernetes上的数字证书

接下来做一个x509数字证书认证测试。以下操作在Master上的/etc/kubernetes/pki目录下进行。

#生成RSA私钥。注意其权限，阻止其它用户读取
umask 077;openssl genrsa -out mason.key 4096
#使用原有的RSA私钥创建证书签署请求，主体信息由选项subj指定，其中CN的值被API Server识别为用户名，O的值被识别为用户组
openssl req -new -key mason.key -out mason.csr -subj '/CN=mason/O=kubeadmin'
#由Kubernetes CA签署证书(指定ca.crt)。这里直接读取相关的csr文件，并将签署后的证书仍然保存在当前系统用户主目录下的.certs中。设置生效时长为3650天
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in mason.csr -out mason.crt
#将pki目录下的ca.crt、mason.key、mason.crt复制到Node节点上即可进行测试，由于Node节点上已有ca.crt文件，故无需复制此文件
scp {mason.key,mason.crt} 192.168.131.14:/etc/kubernetes/pki
#在Node1节点(192.168.131.14)测试。虽然提示权限错误，但用户mason已经被API Server正确识别
kubectl get pod -s https://kubeapi.wxd.com:6443 --client-certificate=./mason.crt --client-key=./mason.key --certificate-authority=./ca.crt

四、kubeconfig配置文件

4.1 介绍

基于无状态协议的HTTP/HTTPS的API Server需要验证每次连接请求中的用户身份，且步骤复杂。为此，Kubernetes设计了一种名为kubeconfig的配置文件，它存储了接入一到多个Kubernetes集群的相关配置信息(包括身份认证信息)，便于客户端加载并认证到API Server。
      kubeconfig配置文件主要部分说明如下：

• clusters：Kuberneres集群的访问端点(API Server地址)列表
• users：认证到API Server的身份凭据列表(eg：token、数字证书)
• contexts：用于指明哪个用户关联到哪个集群(user与cluster建立关联关系的上下文列表)
• current-context：当前默认使用的context

kubectl config的常用子命令有如下几项：

• view：打印kubeconfig文件内容
• set-cluster：设定新的集群信息，以单独的列表保存于cluster配置段
• set-credentials：设置认证凭据，保存为users配置段的一个列表项
• set-context：设置新的上下文信息，保存为contexts配置段的一个列表项
• use-context：设定current-context配置段，确定当前以哪个用户的身份接入到哪个集群之中
• delete-cluster：删除clusters中指定的列表项
• delete-context：删除contexts中指定的列表项
• get-clusters：获取clusters中定义的集群列表
• get-contexts：获取contexts中定义的上下文列表

kubectl config命令的相关操作将针对加载的单个kubeconfig文件进行，它根据其优先级由高到低，依次搜索--kubeconfig选项指定的文件、KUBECONFIG环境变量指定的文件和默认的~/.kube/config文件，以其中任意一种方式加载到配置文件后即可终止搜索过程。不过，kubectl config命令支持同时使用多个kubeconfig文件，以及将多个配置文件合并为一个。

4.2 自定义kubeconfig文件

4.2.1 为静态令牌认证的用户设定一个自定义的kubeconfig文件

1st.定义cluster

添加集群配置，包括集群名称、API Server URL和信任的CA证书；clusters配置段的各列表项名称要统一。配置结果使用--kubeconfig选项保存在当前用户主目录下的.kube/mykube.conf文件中。

cd /etc/kubernetes/pki
kubectl config set-cluster mykube --embed-certs=true --certificate-authority=./ca.crt --server="https://192.168.131.11:6443" --kubeconfig=$HOME/.kube/mykube.conf

2nd.添加User

添加身份凭据，使用静态令牌文件认证的客户端提供令牌即可

kubectl config set-credentials tom --token="a993cf.89d6c2dbecede638" --kubeconfig=$HOME/.kube/mykube.conf

3rd.定义Context

为用户tom的身份凭据和mykube集群建立映射关系

kubectl config set-context tom@mykube --cluster=mykube --user=tom --kubeconfig=$HOME/.kube/mykube.conf

4th.设置Current-Context

kubectl config use-context tom@mykube --kubeconfig=$HOME/.kube/mykube.conf

5th.使用当前的上下文进行测试访问。同样没有列出集群级别资源的权限

kubectl get pods --context='tom@mykube' --kubeconfig=$HOME/.kube/mykube.conf

4.2.2 将基于x509证书认证的mason用户添加至mykube.conf文件

同一个列表下，不同项的名称不相同。

1st.定义Cluster

使用不同的身份凭据访问同一集群时，集群相关的配置无需重复定义

2nd.定义User

添加身份凭据，基于x509客户端证书认证时，需要提供客户端证书和私钥

kubectl config set-credentials mason --embed-certs=true --client-certificate=./mason.crt --client-key=./mason.key --kubecnotallow=$HOME/.kube/mykube.conf

3rd.定义Context

为用户mason的身份凭据和mykube集群建立映射关系

kubectl config set-context mason@mykube --cluster=mykube --user=mason --kubecnotallow=$HOME/.kube/mykube.conf

4th.设置Current-Context

kubectl use-context mason@mykube --kubecnotallow=$HOME/.kube/mykube.conf

4.3 多个kubeconfig文件的合并

可以将多个文件路径以冒号分隔并赋值给KUBECONFIG变量，使kubectl config一次性加载多个文件信息，优先级由高到低为各文件自左而右的次序。合并规则如下：

• 忽略不存在的文件
• 遇到内容无法反序列化的文件时，将生成错误信息
• 文件列表中，第一个设定了特定值或映射键的文件即为生效文件

export KUBECONFIG="/root/.kube/mykube.conf:/etc/kubernetes/admin.conf"

此时用kubectl config view命令查看，可得到这两个文件加载后合并的的内容。

五、ServiceAccount

Pod中的进程在访问API Server时，API Server需要对这类来自Pod资源中的客户端程序进行身份验证，服务账户(Service Account)也是专用于这类场景的账号。
      ServiceAccount是API Server支持的标准资源类型之一。
      每个Pod对象只有一个服务账户，若创建Pod资源时未明确指定，则ServiceAccount准入控制器会为其自动附加当前名称空间中默认的服务账户，其名称通常为default。每个Pod对象可附加其所属名称空间下的一个ServiceAccount资源，且只能附加一个。一个ServiceAccount资源的由其所属名称空间的多个Pod对象共享使用。

Kubernetes系统通过3个独立的组件间的相互协作实现了Pod对象服务账户的自动化过程：ServiceAccount准入控制器、令牌控制器和ServiceAccount控制器。ServiceAccount控制器(打包于Controller Manager当中)负责为名称空间管理相应的资源对象，它需要确保每个名称空间中都存在一个名为default的服务账户对象。ServiceAccount准入控制器内置在API Server中(是一个插件)，负责在创建或更新Pod时按需进行ServiceAccount资源对象的创建或修改。令牌控制器主要用于创建和管理令牌。

六、基于角色的访问控制：RBAC

6.1 Kubernetes的鉴权体系

API Server通过启用的鉴权模块进行鉴权。支持的鉴权模块如下：

• Node：专用的授权模块，它基于kubelet将要运行的Pod向kubelet进行授权
• ABAC(Attribute-based access control，基于属性的访问控制)：通过将属性(包括资源属性、用户属性、对象和环境属性等)组合在一起的策略，将访问权限授予用户
• RBAC(Role-based access control，基于角色的访问控制)：基于企业内个人用户的角色来管理计算机或网路资源的访问的鉴权办法
• Webhook：用于支持同Kubernetes外部的授权机制进行集成

kubeadm部署的集群，默认启用了Node和RBAC。要想配置API Server支持哪些鉴权模块，则在kube-apiserver上使用--authorization-mode选项进行定义，多个模块彼此间用逗号分隔。

6.2 RBAC鉴权模型

RBAC是一种特定的权限管理模型，它把可以施加在资源对象上的动作称为许可权限，这些许可权限能够按需组合在一起构建出角色及其职能，并为用户分配一到多个角色完成权限委派。
      RBAC访问控制模型中，授权操作只能通过角色来完成，主体只有在分配到角色之后才能行使权限，且仅限于其从绑定的各角色之上继承而来的权限。换句话说，用户的权限只有通过角色分配才能获得，无角色委派的用户则不具有任何权限。
      简单地说就是，RBAC它以角色为中心界定谁(在集群或者哪个名称空间范围内)可以操作哪些资源对象。

上图为RBAC简易概览图。结合此图介绍下RBAC的相关概念：

• 实体(Entity)：在RBAC也称为Subject，通常指的是User、Group或ServiceAccount，即动作的发出者
• 角色(Role)：承载资源操作权限的容器
• 资源(Resource)：在RBAC中也称为Object，指代Subject期望操作的目标，比如Secret、Pod和Service对象等。这些资源仅限于/api/v1/…及/apis/<group>/<version>/…起始的路径，其它路径对应的端点被视为”非资源类请求”，例如/api或/healthz等端点
• 动作(Actions)：Subject可以在Object上执行的特定操作，具体的可用动作取决于Kubernetes的定义。资源类对象支持只读(get、list、watch)和读写操作(create、update、patch、delete、deletecollection等)，非资源类端点仅支持get操作
• 角色绑定(Role Binding)：将角色关联至实体上，它能够将角色具体的操作权限赋予给实体。说白了就是让哪个用户扮演啥角色

      RBAC角色的类型如下：

• Cluster级别：称为ClusterRole，定义集群范围内的资源操作权限集合，包括集群级别及名称空间级别的资源对象
• Namespace级别，称为Role，定义名称空间范围内的资源操作权限集合

角色绑定的类型如下：

• Cluster级别：称为ClusterRoleBinding，可将实体(User、Group或ServiceAccount)关联至ClusterRole
• Namespace级别：称为RoleBinding，可将实体关联至ClusterRole或Role。如果是关联到ClusterRole则为降级使用

6.3 默认的ClusterRole和ClusterRoleBinding

启用RBAC鉴权模块时，API Server会自动创建一组ClusterRole和ClusterRoleBinding对象。它们多数都以”system:”为前缀，也有几个面向用户的ClusterRole未使用该前缀，比如cluster-admin、admin等。它们都默认使用”kubernetes.io/bootstrapping=rbac-defaults”这个标签。

默认的ClusterRole大体可分为如下5个类别：

• API发现相关的角色，包括system:basic-user、system:discovery和system:public-info-viewer
• 面向用户的角色，包括cluster-admin、admin、edit和view
• 核心组件专用的角色，包括system:kube-scheduler、system:volume-scheduler、system:kube-controller-manager、system:node和system:node-proxier
• 其它组件专用的角色，包括system:kube-dns、system:node-bootstrapper、system:node-problem-detector和system:monitoring
• 内置控制器专用的角色

关于面向用户的角色的介绍，见下表

表3 面向用户的角色的介绍

6.4 Role和ClusterRole

Role和ClusterRole的资源规范完全相同，该规范未使用spec字段，而是直接使用rules字段嵌套授权规则列表。规则的基本要素是动作(verb)和相关的目标资源，后者支持指定一个或多个资源类型、特定资源类型下的单个或多个具体的资源，以及非资源类型的URL等。在Role和ClusterRole资源上定义的rules也称为PolicyRule，即策略规则，它可以内嵌的字段如下：

• apiGroups <[]string>：目标资源的API群组名称，支持列表格式指定多个组，空值(””)表示核心群组
• resources <[]string>：规则应用的目标资源类型，比如pods、services、deployments等。未同时使用resourceNames字段时，表示指定类型下的所有资源。ResourceAll表示所有资源
• resourceNames <[]string>：可选字段，指定操作适用的具体目标资源名称
• nonResourceURLs <[]string>：用于定义用户有权限访问的网址列表，它并非名称空间级别的资源，因此只能应用于ClusterRole，Role支持此字段仅是为了格式上的兼容，该字段在一条规则中与resources和resourceNames互斥
• verbs <[]string>：可应用在此规则匹配到的所有资源类型的操作列表，可用选项由get、list、create、update、patch、watch、proxy、redirect、delete或deletecollection，为必选字段

如下示例在default名称空间定义了一个名为reader的Role资源，它设定了读取、列出和监视pods和Services资源。

kubectl create role reader --verb=list,get,watch --resource=pods,services -o yaml --dry-run=client -n default > role.yml
vim role.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: reader
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - services
  verbs:
  - list
  - get
  - watch

kubectl apply -f role.yml

如下命令创建一个名为cluster-reader的ClusterRole资源，它针对exercise名称空间设定了读取、列出、监视storageclasses,persistentvolumes,namespaces,deployments资源

kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=storageclasses,persistentvolumes,namespaces,deployments -o yaml > cluster-reader.yaml
vim cluster-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2023-07-10T15:00:59Z"
  name: cluster-reader
  resourceVersion: "788803"
  uid: 6bdc5a46-aaf1-4b5d-b0ea-16cbe51dc2ba
rules:
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - storage.k8s.io
  resources:
  - storageclasses
  verbs:
  - get
  - list
  - watch

6.5 RoleBinding和ClusterRoleBinding

如上创建的Role和ClusterRole，它们只是权限的容器。只有将权限赋予某个账号，那个账号才拥有相关权限。
      RoleBinding负责在名称空间级别向普通账户、服务账户或组分配Role或ClusterRole，而ClusterRoleBinding则只能用于在集群级别分配ClusterRole。但二者的配置规范格式完全相同，它们无spec字段，直接使用subjects和roleRef两个嵌套的字段。其中，subjects的值是一个对象列表，用于给出要绑定的主体，而roleRef的值是单个对象，用于指定要绑定的Role或ClusterRole资源。
      Subjects字段的可嵌套字段如下：

• apiGroup <string>：要引用的主题所属的API群组，对于ServiceAccount类的主体来说默认为””，而User和Group类主体的默认值为”rbac.authorization.k8s.io”
• kind <string>：要引用的资源对象(主体)所属的类别，可用值为User、Group和ServiceAccount，必选字段
• name <string>：引用的主题的名称，必选字段
• namespace <string>：引用的主体所属的名称空间，对于非名称空间类型的主体，例如User和Group，其值必须为空，否则授权插件将返回错误信息

roleRef的可嵌套字段如下：

• apiGroup <string>：引用的资源(Role或ClusterRole)所属的API群组，必选字段
• kind <string>：引用的资源所属类别，可用值为Role或ClusterRole，必选字段
• name <string>：引用的资源(Role或ClusterRole)的名称

如下命令创建一个名为mason-and-reader-role的RoleBinding资源，将用户mason和名为reader的ClusterRole绑定起来。

kubectl create rolebinding mason-and-reader-role --role=reader --user=mason -n default -o yaml

将之前自定义的kubeconfig配置文件mykube.conf拷贝到Node节点进行测试。先设置环境变量KUBECONFIG为mykube.conf，之后用--context选项临时切换用户为mason@mykube进行资源管理，测试结果显示，mason具有default名称空间下Pod和Service资源的列出权限。但是，如果要删除资源就没权限了。

export KUBECONFIG=/root/mykube.conf
kubectl get pod,service --context="mason@mykube"

但是，RoleBinding如果引用ClusterRole的许可权限会降级到仅能在RoleBinding所在的名称空间生效。由于clusterrole使用了cluster-admin，这里使用RoleBinding关联至用户时权限在所在名称空间内有效(含namespace资源自身)。

kubectl create namespace test
kubectl create rolebinding mason-exercise-cluster --clusterrole=cluster-admin --user=mason -n test
kubectl get pod -n test --context="mason@mykube"

要想让mason用户拥有(集群级别)所有名称空间下的所有权限，就要用到ClusterRoleBinding。

kubectl create clusterrolebinding mason-cluster-admin --clusterrole=cluster-admin --user=mason -o yaml

此时，mason拥有的权限就跟admin.conf的默认账号的权限一样。