RBAC
简介
本文旦介绍kubectl的权限控制。
RBAC：Role-Based Access Control
样例
- 在讲解具体的原理之前，先来一个具体的操作
用户：cloud
对命名空间：ns-cloud 具有全部权限
- 具体操作如下
* 在已经设置了kubectl访问集群权限的客户端上进行操作
* 创建存放配置文件的目录
mkdir -p /cloud/kubectl-rbac/
cd /cloud/kubectl-rbac/
openssl genrsa -out cloud.key 2048 # 生成客户端私钥，用于访问集群是做验证
openssl req -new -key cloud.key -out cloud.csr -subj "/CN=cloud/O=siguadantang" # 生成签名请求
openssl x509 -req -in cloud.csr -CA /etc/kubernetes/ssl/ca.crt -CAkey /etc/kubernetes/ssl/ca.key -CAcreateserial -out cloud.crt -days 365 #生成证书，有效期365天
export KUBE_APISERVER=https://10.10.11.200:6443
kubectl config set-cluster cluster.local --certificate-authority=/etc/kubernetes/ssl/ca.crt --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=cloud.kubeconfig
kubectl config set-credentials cloud --client-certificate=/cloud/kubectl-rbac/cloud.crt --client-key=/cloud/kubectl-rbac/cloud.key --embed-certs=true --kubeconfig=cloud.kubeconfig
kubectl config set-context cloud-context --cluster=cluster.local --user=cloud --kubeconfig=cloud.kubeconfig
kubectl config use-context cloud-context --kubeconfig=cloud.kubeconfig
useradd cloud
echo 'cloud:cloud' | chpasswd
mkdir /home/cloud/.kube
mv cloud.kubeconfig /home/cloud/.kube/config
chown cloud:cloud /home/cloud/.kube/config
su - cloud
kubectl config view
exit
* 完成如上的操作就完成了整个配置文件的生成，并在生成配置文件的虚机上进行了配置。
* 创建Role和RoleBinding，文件名为：cloud-rbac.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
annotations:
kubesphere.io/creator: system
kubesphere.io/description: Allows admin access to perform any action on any
resource, it gives full control over every resource in the namespace.
name: cloud-r
namespace: cloud-ns
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cloud-rb
namespace: cloud-ns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: cloud-r
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cloud
* 执行命令：kubectl get role cloud-r -n cloud-ns -o yaml 查看role信息
* 执行命令：kubectl get rolebinding cloud-rb -n cloud-ns -o yaml 查看rolebinding信息
* 执行命令：kubectl create -f cloud-rbac.yml
* 验证：kubectl get all -n cloud 获取到cloud命名空间的所有对象信息
* 验证：kubectl get all --all-namespaces (应该会有错误提示，权限不足等）
## 原理
* 在样例章节，最后两部的验证符合预期，恭喜你操作成功了，如果有问题，自行排查，也可联系我。
* 下面讲一讲rbac的原理，先讲几个对象
### subject
* 主体，这个可以是user，group，sa（service account)等。
### Role和ClusterRole
* 这两个对象是一组权限规则的集合，具体包含哪些权限规则，后面再说，现在只要知道，它里面包含了好多权限规则，例如：对pod的读权限，创建pod的权限，删除service的权限，等等；
* 这两个对象的结构类似
* 这连个对象的唯一不同：Role是针对某个命名空间的，ClusterRole是集群范围的，不受namespace约束
### RoleBinding 和 ClusterRoleBinding
* 这两个对象是纽带，将Role和subject关联到一起。
* 这两个对象结构类似
* 这两个对象的不同：RoleBinding用于将Role和subject关联到一起，受namespace约束；ClusterRoleBinding 是将ClusterRole和subject关联到一起，集群范围的，不受namespace约束
* 介绍完这5个对象，我们来说下思路：rbac就是要实现给某个subject分配指定的权限（Role或者ClusterRole），怎么把权限分配到subject呢，就是通过（RoleBinding 或者 ClusterRoleBinding）。
* 再回头看看上面的例子：创建了一个Role：cloud-r，创建了一个RoleBinding：cloud-rb，在rb中关联了用户和Role，到此可能会问，cloud用户哪里来的呢，不能是随便一个cloud都可以访问吧？
* cloud用户是经过k8s认证授权的用户，再回头看看上面制作证书，对cloud授权的步骤，最终的信息会保存在：cloud.kubeconfig中。你是否了解了呢。如果还不能理解，打开cloud.kubeconfig配置文件看看内容。
* 在service account中不需要执行上面生成证书的操作，只需要创建一个service account的对象即可，当然service account大多数时候是提供给集群（服务）使用的
## 权限分类
* 介绍完上面的样例和原理，我们来看看Role中到底有哪些权限
* 在看权限之前，先看看Role对象的结构
kind: Role apiVersion: rbac.authorization.k8s.io/v1
metadata: (ObjectMeta) rules: (PolicyRule array) - apiGroups: string array 包含资源的APIGroup nonResourceURLs: string array resourceNames: string array 白名单，如果不设置，表示全部允许 resources: string array rule生效的资源列表；ResourceAll代表所有的资源 verbs: string array 动词是应用于此规则中包含的所有资源类型和属性限制的动词列表； VerbAll代表所有类型
* metadata先不讲解，重点关注rules段：
此段可以有多个rule，每个rule有5个字段，此处对每个字段进行解释： * apiGroups：是一个字符串类型的值，表示的是资源的APIGroup * nonResurceURLs: * resourceNames: * resources: 表示资源类型，例如：nodes，configmaps，jobs，pods，deployments * verbs: 表示可对resources进行的操作，例如：get, list, watch, create, update, patch, delete ```
对象|所属组|动作 deployments pods replicasets daemonsets services endpoints configmaps nodes