Kubernetes创建普通账号

kubernetes 装好正常运行一段时间后,会出现要把研发和运维权限分开的场景:

比如:

  • 给某个用户某一指定名称空间下的管理权限
  • 给用户赋予集群的只读权限

非常麻烦,我们这里不讨论过多的概念,从运维的角度出发,简单实用化

我们需要明确三个RBAC最基本的概念

  • Role: 角色,它定义了一组规则,定义了一组对Kubernetes API对象的操作权限
  • RoleBinding: 定义了"被作用者"和"角色"的绑定关系
  • Subject: 被作用者,既可以是"人",也可以是机器,当然也可以是 Kubernetes 中定义的用户(ServiceAccount主要负责kubernetes内置用户)

我们的操作过程流程如下,首先创建客户端证书;其次创建Role角色;再创建RoleBinding,把Subject和Role绑定,就完事了;最后一步是生成 kubectl 的配置文件。

一、创建客户端证书

我们以已建好的阿里 ACK 为例,或者自建好的 Kubernetes 也行;确定已经有了 .kube/config 配置文件,拥有集群最高权限,并且可以正常执行 kubectl 命令。

首先是生成证书,并向集群提出证书请求并签发,脚本如下:

 1#!/bin/sh  
 2
 3useraccount=reader
 4
 5openssl req -new -newkey rsa:4096 -nodes -keyout $useraccount-k8s.key -out $useraccount-k8s.csr -subj "/CN=$useraccount/O=devops"  
 6csr=$(cat $useraccount-k8s.csr | base64 | tr -d '\n')  
 7cat << EOF > k8s-csr.yaml  
 8apiVersion: certificates.k8s.io/v1beta1
 9kind: CertificateSigningRequest
10metadata:
11  name: $useraccount-k8s-access
12spec:
13  groups:
14  - system:authenticated
15  request: $csr
16  usages:
17  - client auth
18EOF
19 
20
21kubectl create -f k8s-csr.yaml  
22kubectl certificate approve $useraccount-k8s-access  
23
24kubectl get csr $useraccount-k8s-access -o jsonpath='{.status.certificate}' | base64 --decode > $useraccount-k8s-access.crt  
25kubectl config view -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' --raw | base64 --decode - > k8s-ca.crt

解释一下:我们定义了一个用户CN=reader,然后向集群发送了证书请求并签发,最终从集群获得了 reader-k8s-access.crt 的客户端证书和 k8s-ca.crt 的 CA 证书。

k8s-csr.yaml 和 reader-k8s.csr 都是中间产物,最终我们有了客户端私钥 reader-k8s.key ,客户端证书 reader-k8s-access.crt ,CA 证书 k8s-ca.crt 这三个有用的文件。

二、创建 Role 角色

 1cat << EOF >> role.yaml
 2apiVersion: rbac.authorization.k8s.io/v1
 3kind: Role
 4metadata:
 5  name: role-pods_reader
 6  namespace: default
 7rules:
 8- apiGroups:
 9  - ""
10  resources:
11  - pods
12  - pods/log
13  verbs:
14  - get
15  - list
16  - watch
17EOF
18
19kubectl apply -f role.yaml

解释:我们创建了一个 role 角色,名字叫做 role-pods_reader,所属命名空间是 default ,它对 pods 和 pods/log 有 get 、list、watch的权限,也就是说role-pods_reader 可以查看 default 空间的 pods 和 pods 的日志。

三、创建 Rolebinding

 1cat << EOF >> rolebinding.yaml
 2apiVersion: rbac.authorization.k8s.io/v1
 3kind: RoleBinding
 4metadata:
 5  name: rolebinding-default_pods_reader
 6  namespace: default
 7roleRef:
 8  apiGroup: rbac.authorization.k8s.io
 9  kind: Role
10  name: role-pods_reader
11subjects:
12- apiGroup: rbac.authorization.k8s.io
13  kind: User
14  name: reader
15EOF
16
17kubectl apply -f rolebinding.yaml

解释:我们创建了一个 rolebinding,名字叫做 rolebinding-default_pods_reader,同样所属命名空间是 default,它绑了两个东西,一个是 role,就是上面第二步创建的 role-pods_reader;另一个是 subject,对应了一个用户,就是我们第一步创建的那个 reader。

四、生成 kubectl 配置文件

 1#!/bin/sh
 2useraccount=reader
 3namespace=default
 4
 5kubectl config set-cluster $(kubectl config view -o jsonpath='{.clusters[0].name}') --server=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}') --certificate-authority=k8s-ca.crt --embed-certs --kubeconfig=$useraccount-k8s-config
 6
 7kubectl config set-credentials $useraccount --client-certificate=$useraccount-k8s-access.crt --client-key=$useraccount-k8s.key --embed-certs --kubeconfig=$useraccount-k8s-config
 8
 9kubectl config set-context $useraccount --cluster=$(kubectl config view -o jsonpath='{.clusters[0].name}') --namespace=$namespace --user=$useraccount --kubeconfig=$useraccount-k8s-config
10
11kubectl config use-context $useraccount --kubeconfig=$useraccount-k8s-config

解释:上面看起来很复杂,其实就是四步,在配置文件里设置 cluster 、设置 credentials 证书、设置 context 上下文、设置当前上下文。

完事后会产生一个完整的 reader-k8s-config 文件,如下:

image-20211109133307250

五、测试

我们验证一下:

1KUBECONFIG=reader-k8s-config kubectl get pods
2
3KUBECONFIG=reader-k8s-config kubectl auth can-i delete pods
4
5KUBECONFIG=reader-k8s-config kubectl auth can-i delete svc
6

这样一个对 default 空间的只读用户就建立好了

六、集群只读用户

我们这里给出集群只读用户的 role,命名 role-cluster_reader

 1kubectl apply -f - <<EOF
 2apiVersion: rbac.authorization.k8s.io/v1
 3kind: ClusterRole
 4metadata:
 5  name: role-cluster_reader
 6rules:
 7- apiGroups:
 8  - ""
 9  resources:
10  - nodes
11  - pods
12  - pods/exec
13  - pods/log
14  - services
15  - configmaps
16  - secrets
17  - serviceaccounts
18  - endpoints
19  verbs:
20  - get
21  - list
22  - watch
23- apiGroups:
24  - apps
25  resources:
26  - deployments
27  - replicasets
28  - daemonsets
29  - statefulsets
30  verbs:
31  - get
32  - list
33  - watch
34- apiGroups:
35  - batch
36  resources:
37  - jobs
38  - cronjobs
39  verbs:
40  - get
41  - list
42  - watch
43EOF

以及 rolebinding,还是绑到第一步的用户 reader 的例子

 1kubectl apply -f - <<EOF
 2apiVersion: rbac.authorization.k8s.io/v1
 3kind: ClusterRoleBinding
 4metadata:
 5  name: rolebinding-cluster_reader
 6roleRef:
 7  apiGroup: rbac.authorization.k8s.io
 8  kind: ClusterRole
 9  name: role-cluster_reader
10subjects:
11- apiGroup: rbac.authorization.k8s.io
12  kind: User
13  name: reader
14EOF

生成配置文件的步骤跟上一步是一样的。

从上面大家可以看到,其实最主要的就是 role 的 yaml 文件,里面控制着到底有怎么样的权限。


Clash的搭建教程
Nginx的一个端口同时跑SSH和HTTPS服务
comments powered by Disqus