什么是 Kubernetes RBAC
基于角色的访问控制（Role-Based Access Control, 即 "RBAC"）：使用 “” API Group
实现授权决策，允许管理员通过 Kubernetes API 动态配置策略。
API 概述
本节将介绍RBAC API所定义的四种顶级类型。用户可以像使用其他Kubernetes API资源一样
（例如通过kubectl、API调用等）与这些资源进行交互。例如，命令 kubectl create -f (resource).yml
可以被用于以下所有的例子，当然，读者在尝试前可能需要先阅读以下相关章节的内容。[1]
RBAC 简易概览图
ClusterRole 与 Role
Role（角色）： 是一系列权限的集合，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限。Role 只能用来给某个特定 namespace 中的资源作鉴权。
对 namespace 、集群级资源 和 非资源类的 API（如 /healthz）使用 ClusterRole
ClusterRole： 对象可以授予与 Role 对象相同的权限，但由于它们属于集群范围对象，也可以使用它们授予对以下几种资源的访问权限：
集群范围资源（例如节点，即 node）
非资源类型 endpoint（例如 /healthz）
授权多个 Namespace
#下面例子描述了 default namespace 中的一个 Role 对象的定义，用于授予对 pod 的读访问权限
kind: Role
apiVersion: /v1beta1
metadata:
namespace: default #有"namespace" 区分，指定default的名称空间
name: demo-role
rules:
- apiGroups: [""] # 空字符串""表明使用 core API group
resources: ["pods"]
verbs: ["get", "watch", "list", "create", "delete"] #创建role实例，在default名称空间
[root@master01 role]# cat pods-reader.yaml
apiVersion: /v1
kind: Role
metadata:
name: pods-reader
namespace: default
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@master01 role]# kubectl apply -f pods-reader.yaml [root@master01 role]# kubectl get role|grep pods-reader
pods-reader 2021-12-23T06:16:36Z ################################################################################
# 下面例子中 ClusterRole 定义可用于授予用户对某一个 namespace，或者
所有 namespace的 secret（取决于其绑定方式）的读访问权限kind: ClusterRole
apiVersion: /v1beta1
metadata:
# ClusterRole 是集群范围对象，没有 "namespace" 区分
name: demo-clusterrole
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list", "create", "delete"]
#创建clusterrole
[root@master01 role]# cat cluster-pods-reader.yaml
kind: ClusterRole
apiVersion: /v1beta1
metadata:
name: csrolereader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]#查看clusterrole
[root@master01 role]# kubectl get clusterrole |grep csrolereader
csrolereader 2021-12-23T07:56:14Z
# ClusterRoleBinding 与 RoleBinding
RoleBinding：
把 Role 中定义的各种权限映射到subjects资源上。
subjects定义：
User，Service Account ， Group，三种账号资源
从而让这些用户继承角色在 namespace 中的权限。ClusterRoleBinding：
把ClusterRole 中定义的各种权限映射到subjects资源上。
subjects定义：
User，Service Account ， Group，三种账号资源
让用户继承 ClusterRole 在整个集群中的权限。所以namespace名称空间， RoleBinding： 可以引用在同一命名空间内定义的Role对象。
#创建一个rolebinding，把subject资源跟role角色绑定，使subject资源需要role角色的权限
[root@master01 role]# cat fengge-pods-reader.yaml
apiVersion: /v1
kind: RoleBinding
metadata:
name: fengge-pods-reader
roleRef:
apiGroup:
kind: Role
name: pods-reader
subjects:
- apiGroup:
kind: User
name: fengge#绑定
[root@master01 role]# kubectl apply -f fengge-pods-reader.yaml
rolebinding./fengge-pods-reader created[root@master01 role]# kubectl get rolebinding|grep fengge-pods-reader
fengge-pods-reader Role/pods-reader 11m#使用fengge用户，验证结果，这里创建的fengge账号，只是为了测试在普通用户下，并不是k8s里面的账号fengge。
[root@master01 role]# useradd fengge
[root@master01 role]# cp -ra /root/.kube /home/fengge/
[root@master01 role]# chown -R fengge.fengge /home/fengge/#切换context上下文
[root@master01 ~]# su - fengge
[fengge@master01 ~]$ kubectl config use-context fengge@k8s-fengge#由于fengge用户绑定的role定义在default名称空间，
[fengge@master01 ~]$ kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
nginx-sa-68485b4475-dz26t 1/1 Running 0 24h
nginx-sa-68485b4475-l6llv 1/1 Running 0 24h#除了default名称空间，其他名称空间都无法访问。
[fengge@master01 ~]$ kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "fengge" cannot list resource "pods" in API group "" in the namespace "kube-system"#把fengge账号跟clusterrole角色进行绑定，一个账号绑定多个角色，那就以权限最大角色为准。但是最好删除账号之前角色绑定，否则会出现权限混乱。
[root@master01 role]# kubectl describe rolebinding fengge-pods-reader
Name: fengge-pods-reader
Labels: <none>
Annotations: Role:
Kind: Role
Name: pods-reader
Subjects: #fengge账号绑定pods-reader这个role角色
Kind Name Namespace
---- ---- ---------
User fengge
#删除rolebinding
[root@master01 role]# kubectl delete rolebinding fengge-pods-reader
rolebinding. "fengge-pods-reader" deleted
[root@master01 role]# cat cluster-fengge-pods-reader.yaml
apiVersion: /v1
kind: ClusterRoleBinding
metadata:
name: cs-pods-reader
roleRef:
apiGroup:
kind: ClusterRole
name: csrolereader
subjects:
- apiGroup:
kind: User
name: fengge#fengge账号绑定clusterrolebinding
[root@master01 role]# kubectl apply -f cluster-fengge-pods-reader.yaml
[root@master01 role]# kubectl get clusterrolebinding|grep cs
cs-pods-reader ClusterRole/csrolereader #再次切换fengge账号进行验证，
[root@master01 ~]# su - fengge
[fengge@master01 ~]$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.4.7.48:6443
name: k8s-fengge
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.4.7.48:6443
name: kubernetes
contexts:
- context:
cluster: k8s-fengge
user: fengge
name: fengge@k8s-fengge
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: fengge@k8s-fengge #当前fengge账号，如果context不是fengge，需要切换为fengge用户
kind: Config
preferences: {}
users:
- name: fengge
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
[fengge@master01 ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-sa-68485b4475-dz26t 1/1 Running 0 24h
nginx-sa-68485b4475-l6llv 1/1 Running 0 24h#之前fengge账号绑定是role角色无法查看kube-system名称空间，但是绑定clusterrole就可以查看所以名称空间clusterrole定义的权限。
[fengge@master01 ~]$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-55b448c5dd-fg6dn 1/1 Running 0 8d
coredns-55b448c5dd-lptwc 1/1 Running 0 8d
etcd-master01 1/1 Running 3 8d
etcd-master02 1/1 Running 1 8d
kube-apiserver-master01 1/1 Running 6 8d RoleBinding：
对象也可以引用一个 ClusterRole 对象用于在 RoleBinding 所在的命名空间内授予用户对所引
用的ClusterRole 中定义的命名空间资源的访问权限。这一点允许管理员在整个集群范围内首先
定义一组通用的角色，然后再在不同的命名空间中复用这些角色。例如，尽管下面示例中的 RoleBinding 引用的是一个 ClusterRole 对象，
但是用户”dave”（即角色绑定主体）还是只能读取”development” 命名空间中的 secret（即RoleBinding所在的命名空间）# 以下角色绑定允许用户"fengge"读取"kube-system"命名空间中的
# 先删除上面的fengge账号的clusterrolebinding。
[root@master01 role]# kubectl delete clusterrolebinding cs-pods-reader
clusterrolebinding. "cs-pods-reader" deleted#rolebinding绑定clusterrole，这个时候clusterrole只能访问rolebinding定义的namespace的clusterrole定义的verbs权限。
[root@master01 role]# cat rolebinding-clusterrole.yaml
kind: RoleBinding
apiVersion: /v1beta1
metadata:
name: read-kubens
namespace: kube-system # 这里表明仅授权读取"kube-system"命名空间中的资源。
subjects:
- kind: User
name: fengge
apiGroup:
roleRef:
kind: ClusterRole
name: csrolereader
apiGroup: #通过rolebinding绑定clusterrole
[root@master01 role]# kubectl apply -f rolebinding-clusterrole.yaml
rolebinding./read-kubens created
#查看rolebinding是否创建成功，由于role角色是基于namespace的，rolebinding定义在kube-system名称空间，
所以rolebinding创建就在kube-system名称空间里
[root@master01 role]# kubectl get rolebinding -n kube-system |grep read-kubens
read-kubens ClusterRole/csrolereader 3m3s
#可以使用 ClusterRoleBinding 在集群级别和所有命名空间中授予权限。
下面示例中所定义的 ClusterRoleBinding 允许在用户组 ”manager” 中的任何用户都可以读取集群中任何命名空间中的 secret 。 3.设置fengge账号为指定名称空间管理员。
#查看k8s集群的clusterrole，下面的admin。cluster-admin等都是最高权限的
[root@master01 role]# kubectl get clusterrole|head
NAME CREATED AT
admin 2021-12-15T04:07:48Z
cluster-admin 2021-12-15T04:07:48Z
csrolereader 2021-12-23T07:56:14Z
edit 2021-12-15T04:07:48Z
flannel 2021-12-15T04:21:05Z
kubeadm:get-nodes 2021-12-15T04:07:51Z
nginx-ingress-clusterrole 2021-12-15T09:56:53Z
system:aggregate-to-admin 2021-12-15T04:07:48Z
system:aggregate-to-edit 2021-12-15T04:07:48Z#查看clusterrole的admin角色
[root@master01 role]# kubectl get clusterrole admin -o yaml#删除rolebinding
[root@master01 role]# kubectl delete rolebinding read-kubens -n kube-system
rolebinding. "read-kubens" deleted#把fengge这个账号设置为管理员账号，某个namespace名称空间的，由于当前clusterrole角色有admin，cluster-admin，
可以把fengge用户绑定到这两个的任何一个集群角色上，用rolebinding限制到某一个名称空间
#创建rolebinding文件
[root@master01 role]# cat rolebinding-admin-clusterrole.yaml
kind: RoleBinding
apiVersion: /v1beta1
metadata:
name: default-admin
namespace: default # 这里表明仅授权读取"default"命名空间中的资源。
subjects:
- kind: User
name: fengge
apiGroup:
roleRef:
kind: ClusterRole
name: admin
apiGroup: #执行
[root@master01 role]# kubectl apply -f rolebinding-admin-clusterrole.yaml
rolebinding./default-admin created#查看，因为rolebinding定义在default名称空间
[root@master01 role]# kubectl get rolebinding -n default|grep default-admin
default-admin ClusterRole/admin 21s#现在fengge账号具有default名称空间的管理权限，
[fengge@master01 ~]$ kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
nginx-sa-68485b4475-dz26t 1/1 Running 0 25h
nginx-sa-68485b4475-l6llv 1/1 Running 0 25h#删除pod
[fengge@master01 ~]$ kubectl delete pod nginx-sa-68485b4475-dz26t
pod "nginx-sa-68485b4475-dz26t" deleted#查看pod旧的被删除，
[fengge@master01 ~]$ kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
nginx-sa-68485b4475-bng9w 1/1 Running 0 6s
nginx-sa-68485b4475-l6llv 1/1 Running 0 25h#查看其他名称空间都是提示无法访问，权限不够
[fengge@master01 ~]$ kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "fengge" cannot list resource "pods" in API group "" in the namespace "kube-system"
[fengge@master01 ~]$ #serviceaccount用户是在pod容器里，是指定pod具有什么样的权限
查看kube-flannel.yml 文件，里面就定义了serviceaccount，进行集群角色绑定
[root@master01 ~]# cat kube-flannel.yml
。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。。。
kind: ClusterRole #定义集群角色
apiVersion: /v1beta1
metadata:
name: flannel
rules:
- apiGroups: ['extensions']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames: ['psp.flannel.unprivileged']
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
---
kind: ClusterRoleBinding #集群角色绑定
apiVersion: /v1beta1
metadata:
name: flannel
roleRef:
apiGroup:
kind: ClusterRole
name: flannel
subjects:
- kind: ServiceAccount
name: flannel
namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount #定义了serviceaccount
metadata:
name: flannel
namespace: kube-system
---
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。#在kube-system名称空间就有flannel这个sa账号
[root@master01 ~]# kubectl get sa -n kube-system|grep flannel
flannel 1 8d#同时这个文件里daemset也对container指定了serviceaccount的名字flannel
[root@master01 ~]# cat kube-flannel.yml
。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。
hostNetwork: true
tolerations:
- operator: Exists
effect: NoSchedule
serviceAccountName: flannel #下面container指定serviceaccountname
initContainers:
- name: install-cni
image: quay.io/coreos/flannel:v0.11.0-ppc64le
command:
- cp
args:
- -f
- /etc/kube-flannel/cni-conf.json
- /etc/cni/net.d/10-flannel.conflist
volumeMounts:
- name: cni
mountPath: /etc/cni/net.d
- name: flannel-cfg
mountPath: /etc/kube-flannel/
containers: #container定义
- name: kube-flannel
image: quay.io/coreos/flannel:v0.11.0-ppc64le
command:
- /opt/bin/flanneld
args: 4.对资源的引用
大多数资源由代表其名字的字符串表示，例如 ”pods”，就像它们出现在相关API endpoint 的URL中一样。
然而，有一些Kubernetes API还 包含了”子资源”，比如 pod 的 logs。在Kubernetes中，pod logs endpoint的URL格式为：GET /api/v1/namespaces/{namespace}/pods/{name}/log
在这种情况下，”pods”是命名空间资源，而”log”是pods的子资源。为了在RBAC角色中表示出这一点，
我们需要使用斜线来划分资源 与子资源。如果需要角色绑定主体读取pods以及pod log，您需要定义以下角色：kind: Role
apiVersion: /v1beta1
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
通过 resourceNames 列表，角色可以针对不同种类的请求根据资源名引用资源实例。当指定了 resourceNames 列表时，不同动作 种类的请求的权限，如使用 ”get”、”delete”、”update”以及”patch”等动词的请求，将被限定到资源列表中所包含的资源实例上。 例如，如果需要限定一个角色绑定主体只能 ”get” 或者 ”update” 一个 configmap 时，您可以定义以下角色：kind: Role
apiVersion: /v1beta1
metadata:
namespace: default
name: configmap-updater
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]
值得注意的是，如果设置了 resourceNames，则请求所使用的动词不能是 list、watch、create或者deletecollection。 由于资源名不会出现在 create、list、watch和deletecollection 等API请求的URL中，所以这些请求动词不会被设置了resourceNames 的规则所允许，因为规则中的 resourceNames 部分不会匹配这些请求。 [1]例子
绑定用户能查看所有 namespace
apiVersion: /v1
kind: ClusterRole
metadata:
# 鉴于ClusterRole是集群范围对象，所以这里不需要定 义"namespace"字段
name: view-namespace-clusterrole
rules:
- apiGroups:
- ""
resources:
- namespaces
- namespaces/status
verbs:
- get
- list
- watch
定义 develop-role 用户对 default 命名空间详细权限
apiVersion: /v1
kind: Role
metadata:
name: develop-role
namespace: default
rules:
- apiGroups:
- ""
resources:
- endpoints
- serviceaccounts
- configmaps
- persistentvolumeclaims
- persistentvolumes
- services
- replicationcontrollers
- replicationcontrollers/scale
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
- pods/log
- pods/status
- pods/exec
verbs:
- create
- delete
- deletecollection
- patch
- update
- get
- list
- watch
- apiGroups:
- ""
resources:
- bindings
- events
- limitranges
- namespaces/status
- replicationcontrollers/status
- resourcequotas
- resourcequotas/status
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- apps
resources:
- daemonsets
- statefulsets
verbs:
- get
- list
- watch
- apiGroups:
- apps
resources:
- deployments
- deployments/scale
- replicasets
- replicasets/scale
verbs:
- get
- list
- watch
- update
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
verbs:
- get
- list
- watch
- apiGroups:
- batch
resources:
- cronjobs
- jobs
verbs:
- get
- list
- watch
- apiGroups:
- extensions
resources:
- daemonsets
- statefulsets
- ingresses
- networkpolicies
verbs:
- get
- list
- watch
- apiGroups:
- extensions
resources:
- deployments
- deployments/scale
- replicasets
- replicasets/scale
- replicationcontrollers/scale
verbs:
- get
- list
- watch
- update
- apiGroups:
- policy
resources:
- poddisruptionbudgets
verbs:
- get
- list
- watch
- apiGroups:
-
resources:
- networkpolicies
verbs:
- get
- list
- watch
默认角色 与 默认角色绑定
API Server 会创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 这些默认对象中有许多包含 system: 前缀，
表明这些资源由 Kubernetes基础组件”拥有”。 对这些资源的修改可能导致非功能性集群（non-functional cluster）。
一个例子是 system:node ClusterRole 对象。 这个角色定义了 kubelet 的权限。如果这个角色被修改，
可能会导致kubelet 无法正常工作。所有默认的 ClusterRole 和 ClusterRoleBinding 对象都会被标记为 kubernetes.io/bootstrapping=rbac-defaults。 [1]
面向用户的角色
通过命令 kubectl get clusterrole 查看到并不是所有都是以 system:前缀，它们是面向用户的角色。
这些角色包含超级用户角色（cluster-admin），即旨在利用 ClusterRoleBinding（cluster-status）
在集群范围内授权的角色， 以及那些使用 RoleBinding（admin、edit和view）在特定命名空间中授权的角色。cluster-admin：超级用户权限，允许对任何资源执行任何操作。 在 ClusterRoleBinding 中使用时，
可以完全控制集群和所有命名空间中的所有资源。 在 RoleBinding 中使用时，可以完全控制 RoleBinding 所在命名空间中的所有资源，包括命名空间自己。
admin：管理员权限，利用 RoleBinding 在某一命名空间内部授予。 在 RoleBinding 中使用时，允许针对命名空间内大部分资源的读写访问， 包括在命名空间内创建角色与角色绑定的能力。 但不允许对资源配额（resource quota）或者命名空间本身的写访问。
edit：允许对某一个命名空间内大部分对象的读写访问，但不允许查看或者修改角色或者角色绑定。
view：允许对某一个命名空间内大部分对象的只读访问。 不允许查看角色或者角色绑定。 由于可扩散性等原因，不允许查看 secret 资源。
核心组件角色、其它组件角色 和 控制器（Controller）角色 这里不在一一列出。具体见参考链接中[1]。Permissive RBAC
所谓 Permissive RBAC 是指授权给所有的 Service Accounts 管理员权限。不推荐的配置$ kubectl create clusterrolebinding permissive-binding \
--clusterrole=cluster-admin \
--user=admin \
--user=kubelet \
--group=system:serviceaccounts
创建用户 shell 脚本
#!/usr/bin/env bash
# 注意修改KUBE_APISERVER为你的API Server的地址KUBE_APISERVER=$1
USER=$2
USER_SA=system:serviceaccount:default:${USER}
Authorization=$3
USAGE="USAGE: <api_server> <username> <clusterrole authorization>\n
Example: https://192.168.1.2:6443 brand"
CSR=`pwd`/user-csr.json
SSL_PATH="/opt/kubernetes/ssl"
USER_SSL_PATH="/opt/kubernetes/create-user"
SSL_FILES=(ca-key.pem ca.pem ca-config.json)
CERT_FILES=(${USER}.csr $USER-key.pem ${USER}.pem)if [[ $KUBE_APISERVER == "" ]]; then
echo -e $USAGE
exit 1
fi
if [[ $USER == "" ]];then
echo -e $USAGE
exit 1
fiif [[ $Authorization == "" ]];then
echo -e $USAGE
exit 1
fi# 创建用户的csr文件
function createCSR(){
cat>$CSR<<EOF
{
"CN": "USER",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "BeiJing",
"L": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
EOF# 替换csr文件中的用户名
sed -i "s/USER/$USER_SA/g" $CSR
}function ifExist(){
if [ ! -f "$SSL_PATH/$1" ]; then
echo "$SSL_PATH/$1 not found."
exit 1
fi
}function ifClusterrole(){
kubectl get clusterrole ${Authorization} &> /dev/null
if (( $? !=0 ));then
echo "${Authorization} clusterrole there is no"
exit 1
fi
}# 判断clusterrole授权是否存在
ifClusterrole# 判断证书文件是否存在
for f in ${SSL_FILES[@]};
do
echo "Check if ssl file $f exist..."
ifExist $f
echo "OK"
doneecho "Create CSR file..."
createCSR
echo "$CSR created"
echo "Create user's certificates and keys..."
cd $USER_SSL_PATH
cfssl gencert -ca=${SSL_PATH}/ca.pem -ca-key=${SSL_PATH}/ca-key.pem -config=${SSL_PATH}/ca-config.json -profile=kubernetes $CSR| cfssljson -bare $USER_SA# 创建 sa
kubectl create sa ${USER} -n default# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=${SSL_PATH}/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=${USER}.kubeconfig# 设置客户端认证参数
kubectl config set-credentials ${USER_SA} \
--client-certificate=${USER_SSL_PATH}/${USER_SA}.pem \
--client-key=${USER_SSL_PATH}/${USER_SA}-key.pem \
--embed-certs=true \
--kubeconfig=${USER}.kubeconfig# 设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=${USER_SA} \
--namespace=development \
--kubeconfig=${USER}.kubeconfig# 设置默认上下文
kubectl config use-context kubernetes --kubeconfig=${USER}.kubeconfig# 创建 namespace
# kubectl create ns $USER# 绑定角色
# kubectl create rolebinding ${USER}-admin-binding --clusterrole=admin --user=$USER --namespace=$USER --serviceaccount=$USER:default
kubectl create clusterrolebinding ${USER}-binding --clusterrole=${Authorization} --user=${USER_SA}# kubectl config get-contexts
echo "Congratulations!"
echo "Your kubeconfig file is ${USER}.kubeconfig"本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
