前言
kubernetes 集群相关所有的交互都通过apiserver来完成，对于这样集中式管理的系统来说，权限管理尤其重要，在1.5版的时候引入了RBAC(Role Base Access Control)的权限控制机制.
RBAC也是初接触k8s的用户较难理解的一部分，同时RBAC作为集群管理的基础组件之一，本该放在最前面几篇，但是最近才想起来这个方面的知识点，赶紧梳理总结输出了本篇
工作流程
流程图
流程拆解
一、基于资源申明和管理方法申明组成rule规则，和Role(命名空间范围))或ClusterRole(集群范围)对象进行绑定，Role类的对象将拥有所申明资源及的指定方法的权限。
二、将Role权限落到实际用户或程序上，即RoleBinding(命名空间范围)或CLusterRoleBinding(集群范围)
有两种方式：
1.用户使用：如果是用户需求权限，则将Role与User(或Group)绑定(这需要创建User/Group)；
2.程序使用：如果是程序需求权限，将Role与ServiceAccount指定(这需要创建ServiceAccount并且在deployment中指定ServiceAccount)。
相当于Role是一个类，用作权限申明，User/Group/ServiceAccount将成为类的实例
实战
一、用户使用
安装cfssl工具，生成ca-config.json文件。这一步骤在安装集群的时候已经做过，这里不再复述，参考：
k8s（一）、 1.9.0高可用集群本地离线部署记录
准备ca配置json文件如下：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20cat > ca-config.json <<EOF
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
EOF
安装好的k8s集群，默认在ca文件在如下路径：
1 | ～ /rbac-test# ls /etc/kubernetes/pki/ca* |
创建用户的证书签署请求配置json文件：
1 | ~/rbac-test# cat opsuser-csr.json |
CN即comman name，后面用户证书认证时使用的用户名
生成opsuser的证书：
1 | cfssl gencert -ca=/etc/kubernetes/pki/ca.crt -ca-key=/etc/kubernetes/pki/ca.key -config=./ca-config.json -profile=kubernetes ./opsuser-csr.json | cfssljson -bare opsuser |
会生成下面3个文件：
1 | opsuser-key.pem opsuser.pem opsuser.csr |
生成用户的专属配置文件
完整的配置文件包含3块，分别是cluster/context/user部分，包含相应的内容，分3个步骤生成，后方详解
1.cluster部分：
生成此部分需要有集群的ca.pem文件，此文件在/etc/kubernetes/pki目录下默认没有，可以使用openssl命令基于ca.key文件去生成ca.pem文件；也可以直接使用已有的/etc/kubernetes/admin.conf文件中cluster部分：
1 | # 只取cluster的上下文 |
2.context部分
1 | kubectl config set-context kubernetes \ |
3.user认证部分
1 | kubectl config set-credentials opsuser \ |
查看最终生成的配置文件：
1 | # cat opsuser.kubeconfig |
最后，加载启用此配置文件
1 | kubectl config use-context kubernetes --kubeconfig=opsuser.kubeconfig |
此时，用户已经创建完成，下面开始进行RoleBinding步骤赋予权限。
RoleBinding绑定
创建Role：
1 | ~/rbac-test |
RoleBinding步骤已完成
检验
1 | # 将此配置文件作为当前kubectl配置文件使用 |
可以看到，基于生成的用户配置文件，已经可以管理申明的pod资源，无法管理申明以外的资源类型。测试成功
二、程序使用
与用户使用User不同的是，程序的权限赋予是通过ServiceAccount来作为权限载体的，因此，首先要拥有程序/deployment/ServiceAccount等资源，这里以前面文章里没有讲的kube dashboard为例进行说明。
首先我们来看官方最新版本的kube dashboard的yaml文件(服务暴露方式稍作修改成了NodePort)：
1 | ~/dashboard# cat kubernetes-dashboard.yaml |
部署dashboard：
1 | kubectl apply -f kubernetes-dashboard.yaml |
浏览器访问dashboard需要token，或者kube-config文件，这里使用token，在创建好ServiceAccount且和role进行bind绑定之后，会自动创建一个名为${ServiceAccountName}-token-xxx 的Secret，其内包含token，为base64编码，可以使用kubectl describe直接查看：
1 | :~/dashboard# kubectl get secret -o wide -n kube-system | grep kubernetes-dashboard |
使用此token登录dashboard：
第二张截图可以发现，dashboard无多种资源类型的list权限，这是因为在上面的yaml文件中，定义的role权限是限定的：
1 | # ------------------- Dashboard Role & Role Binding ------------------- # |
可以修改这里的Role内部的权限，也可以自行配置更高级的权限，我这里为了方便，直接配置了一个admin的ServiceAccount:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25~/dashboard# cat admin-token.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: admin
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
kind: ClusterRole # ClusterRole拥有集群级别权限，于此同时绑定时不能再使用RoleBinding而应该使用ClusterRoleBinding
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: admin
namespace: kube-system
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
创建：
1 | ~/dashboard# kubectl apply -f admin-token.yaml |
查看token：
1 | :~/dashboard# kubectl get secret -n kube-system | grep admin |
dashboard退出之前的账号，使用admin-token重新登录，可以发现已经拥有全部权限：
总结
k8s角色授权使用的流程有多个环节多种资源类型搭配完成，权限粒度明确、用户与进程分工有序，理解了顶部的流程图，相信你将不再为RBAC疑惑。
