k8s-權(quán)限管理
共 27183字,需瀏覽 55分鐘
·
2024-06-18 17:24
目錄
1. 身份認(rèn)證
1. 生成token
在apiserver加入?yún)?shù)
2. 嘗試登錄集群
3. 帶上參數(shù)再次嘗試
1. 生成私鑰
2. 生成zhangsan用戶證書請求文件
3. 為zhangsan用戶頒發(fā)證書
4. 創(chuàng)建命名空間及pod
5. 創(chuàng)建角色
6. 綁定角色給用戶
7. 編輯kubeconfig文件
8. 嵌入密鑰文件
9. 驗(yàn)證權(quán)限
node節(jié)點(diǎn)操作
創(chuàng)建普通用戶并授權(quán)
靜態(tài)token登錄
2. 角色授權(quán)
1. 創(chuàng)建一個新的用戶,使用token
2. 創(chuàng)建clusterrole
3. clusterrolebinding
4. 驗(yàn)證權(quán)限
1. 創(chuàng)建角色
2. rolebinding
3. 驗(yàn)證權(quán)限
4. 修改權(quán)限
5. 驗(yàn)證是否成功增加權(quán)限
6. deploymentde的操作
role與rolebinding
clusterrole和clusterrolebinding
1. 身份認(rèn)證
我們在目前的k8s集群環(huán)境里面,只能在master節(jié)點(diǎn)上執(zhí)行kubectl的一些命令,在其他節(jié)點(diǎn)上執(zhí)行就會報錯
# 看一下是不是
[root@node1 ~]# kubectl get nodes
E0220 12:50:15.695133 6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused
E0220 12:50:15.695771 6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused
E0220 12:50:15.697555 6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused
E0220 12:50:15.699191 6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused
E0220 12:50:15.700655 6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused
The connection to the server localhost:8080 was refused - did you specify the right host or port?
我們可以看到在node1上執(zhí)行kubectl get nodes都會報錯,那就更不談創(chuàng)建pod之類的操作了,那為什么master可以而其他節(jié)點(diǎn)不行呢?
這是因?yàn)樵趍aster節(jié)點(diǎn)上是有一個kubeconfig的
[root@master ~]# env |grep -i kubeconfig
KUBECONFIG=/etc/kubernetes/admin.conf
我們可以看到在master節(jié)點(diǎn)上是有一個環(huán)境變量加載了這個admin.conf這個文件的,這個文件就是k8s集群默認(rèn)的管理員文件,換一種說法,只要你有本事偷走這個文件并且保障你的網(wǎng)絡(luò)跟這個集群的網(wǎng)絡(luò)是通的,那么恭喜你,得到了一個k8s集群
node節(jié)點(diǎn)操作
我們現(xiàn)在來將這個admin.conf傳到node1上,再來看看node1能不能去執(zhí)行命令
# 傳文件
[root@master ~]# scp /etc/kubernetes/admin.conf node1:~
admin.conf 100% 5669 6.2MB/s 00:00
# 在node1上執(zhí)行命令看看效果
[root@node1 ~]# kubectl get node --kubeconfig=admin.conf
NAME STATUS ROLES AGE VERSION
master Ready control-plane,master 43d v1.26.0
node1 Ready node1 43d v1.26.0
node2 Ready node2 43d v1.26.0
我們通過這個小實(shí)驗(yàn)看到,node1節(jié)點(diǎn)確實(shí)是可以獲取到節(jié)點(diǎn)信息了,但是他執(zhí)行的命令跟master上有所不同,在node1上執(zhí)行的時候他是需要執(zhí)行配置文件的,如果你不想執(zhí)行的話可以將這個注冊到環(huán)境變量里面
[root@node1 ~]# echo "export KUBECONFIG=/root/admin.conf" >> /etc/profile
[root@node1 ~]# tail -1 /etc/profile
export KUBECONFIG=/root/admin.conf
只需要這樣就好了
但是這樣存在一個問題,他們用的都是管理員的配置文件,那么就相當(dāng)于他們都是管理員,對集群有全部權(quán)限,我們追求是的最小權(quán)限原則,就是我給你的權(quán)限正好能夠讓你完成屬于你自己的任務(wù),多的權(quán)限不應(yīng)該有,那么我們能不能像Linux一樣創(chuàng)建普通用戶,給普通用戶定制權(quán)限呢?當(dāng)然是可以的
創(chuàng)建普通用戶并授權(quán)
我們現(xiàn)在來創(chuàng)建一個普通用戶zhangsan并授權(quán)
1. 生成私鑰
# 使用openssl生成一個rsa類型的私鑰,私鑰文件名是client.key 2048位
[root@master ca]# openssl genrsa -out client.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
........................+++++
...............................................................................................................................................................................................................................................+++++
e is 65537 (0x010001)
[root@master ca]# ls
client.key
2. 生成zhangsan用戶證書請求文件
# 使用client.key 生成一個新的文件叫做client.csr
[root@master ca]# openssl req -new -key client.key -subj "/CN=zhangsan" -out client.csr
[root@master ca]# ls
client.csr client.key
3. 為zhangsan用戶頒發(fā)證書
zhangsan用戶如何將請求發(fā)送給k8s的ca進(jìn)行證書頒發(fā)呢?這個時候我們可以使用k8s自帶的ca來頒發(fā)證書
# k8s的ca在/etc/kubernetes/pki下
[root@master ca]# openssl x509 -req -in client.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out client.crt -days 3650
Signature ok
subject=CN = zhangsan
Getting CA Private Key
# 拷貝ca到當(dāng)前目錄
[root@master ca]# cp /etc/kubernetes/pki/ca.crt .
[root@master ca]# ls
ca.crt client.crt client.csr client.key
4. 創(chuàng)建命名空間及pod
[root@master ca]# kubectl create ns zhangsan
namespace/zhangsan created
# 切到這個命名空間
[root@master ca]# kubectl config set-context --current --namespace zhangsan
Context "kubernetes-admin@kubernetes" modified.
# 創(chuàng)建一個pod
[root@master ca]# kubectl run test01 --image nginx --image-pull-policy IfNotPresent
pod/test01 created
[root@master ca]# kubectl get pods
NAME READY STATUS RESTARTS AGE
test01 1/1 Running 0 13s
5. 創(chuàng)建角色
角色是什么呢?我們可以這樣想,假如我們現(xiàn)在有增刪改查4個權(quán)限,用戶用張三,李四,王五,那我們現(xiàn)在給他們授權(quán)的話只能是一個權(quán)限一個權(quán)限的去給,萬一后面又新增了用戶我們依舊是一個個去指定,過于麻煩,而角色就是介于權(quán)限與用戶之間的一個模板,就像這樣
我們指定了一個角色是管理員,擁有增刪改查4個權(quán)限
一個是開發(fā)的角色,擁有增改查的權(quán)限
一個是普通用戶角色,只有查的權(quán)限
我們指定好這3個模板之后,后面新來的用戶只需要知道他的作用是什么,比如他就是一個普通用戶,那我們直接把這個模板給他套上,那他就只有查的權(quán)限,來了一個開發(fā)者,那我們就給他開發(fā)的這個角色模板,他就自然而然的擁有增改查的權(quán)限
# 這里的pod-reader是role的名字 后面的--verb就是這個角色所包含哪些權(quán)限,并且這個角色所能操作的資源對象僅僅只有pod
[root@master ca]# kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
role.rbac.authorization.k8s.io/pod-reader created
6. 綁定角色給用戶
# 創(chuàng)建一個rolebinding名字叫zhangsan,這個zhangsan并不是用戶張三,而是這個rolebinding的名字,后面--user這個才是用戶張三
[root@master ca]# kubectl create rolebinding zhangsan --role pod-reader --user zhangsan
rolebinding.rbac.authorization.k8s.io/zhangsan created
[root@master ca]# kubectl get rolebindings.rbac.authorization.k8s.io
NAME ROLE AGE
zhangsan Role/pod-reader 4s
7. 編輯kubeconfig文件
關(guān)于這個文件的框架,我們可以到官網(wǎng)去找到
地址 https://kubernetes.io/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/
在官網(wǎng)找到之后我們只需要做一些修改就行,改成這樣就可以,直接復(fù)制這個去改也行
apiVersion: v1
kind: Config
clusters:
- cluster:
name: cluster-zs
users:
- name: zhangsan
contexts:
- context:
name: context-zs
namespace: zhangsan
current-context: "context-zs"
這個文件就寫好了,但是目前來看他與管理員的那個admin.conf好像不一樣,那個文件里面內(nèi)容很多,這個很少
這是因?yàn)槲覀冞€沒有將剛剛創(chuàng)建出來的那些密鑰文件嵌入進(jìn)去
8. 嵌入密鑰文件
# 1. 嵌入ca文件
# set-cluster與剛剛文件里的一樣就好了 server地址就是master的ip加上6443端口
[root@master ca]# kubectl config --kubeconfig=kube-zhangsan set-cluster cluster-zs --server=https://192.168.200.200:6443 --certificate-authority=ca.crt --embed-certs=true
Cluster "cluster-zs" set.
# 2. 嵌入client
[root@master ca]# kubectl config --kubeconfig=kube-zhangsan set-credentials zhangsan --client-certificate=client.crt --client-key=client.key --embed-certs=true
User "zhangsan" set.
# 3. 設(shè)置上下文信息
[root@master ca]# kubectl config --kubeconfig=kube-zhangsan set-context context-zs --cluster=cluster-zs --namespace=zhangsan --user=zhangsan
Context "context-zs" modified.
這3個操作搞定之后,你再去看看這個文件,你會發(fā)現(xiàn)他跟admin.conf是一樣一樣的了
9. 驗(yàn)證權(quán)限
這個文件我們就算搞定了,我們來看看使用這個文件所擁有的權(quán)限是否是與我們預(yù)期的一樣
[root@node1 ~]# kubectl get pods --kubeconfig=kube-zhangsan
NAME READY STATUS RESTARTS AGE
test01 1/1 Running 0 9m
# 可以看到pod,我們嘗試一下能否創(chuàng)建pod
[root@node1 ~]# kubectl run test02 --image nginx --kubeconfig=kube-zhangsan
Error from server (Forbidden): pods is forbidden: User "zhangsan" cannot create resource "pods" in API group "" in the namespace "zhangsan"
# 我們看報錯信息,用戶zhangsan是不能創(chuàng)建的,我們來看看除了pod之外的其他資源是否可見
[root@node1 ~]# kubectl get ns --kubeconfig=kube-zhangsan
Error from server (Forbidden): namespaces is forbidden: User "zhangsan" cannot list resource "namespaces" in API group "" at the cluster scope
現(xiàn)在這個文件符合我們預(yù)期的權(quán)限,那么這就是創(chuàng)建一個用戶并授權(quán)的過程
靜態(tài)token登錄
這個方法用人話來講就是,賬號密碼登錄
靜態(tài)的方式就是創(chuàng)建一個csv文件,csv文件的格式是
token,user,id
token這一欄我們可以使用openssl生成
1. 生成token
# 注意文件位置,最好放在/etc/kubernetes/pki下,因?yàn)閗8s默認(rèn)只對/etc/kubernetes這個目錄有權(quán)限操作,放在其他位置可能會產(chǎn)生權(quán)限錯誤
[root@master pki]# openssl rand -hex 10 > jerry.csv
[root@master pki]# cat jerry.csv
# 這里的用戶名和id可以自己改動
3127c2e2b863d4c23878a,jerry,2000
在apiserver加入?yún)?shù)
# 默認(rèn)情況下你剛剛寫的文件與集群是沒有任何關(guān)聯(lián)的,如果想要產(chǎn)生作用需要在kube-apiserver文件加入?yún)?shù)
[root@master manifests]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
# 在這里加上 --token-auth-file后面就是你剛剛的那個文件
- --token-auth-file=/etc/kubernetes/pki/jerry.csv
- --advertise-address=192.168.200.200
- --allow-privileged=true
# 然后重啟kubelet
[root@master pki]# systemctl restart kubelet
2. 嘗試登錄集群
[root@node1 pki]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" get pod -n default
Unable to connect to the server: x509: certificate signed by unknown authority
他會有一個報錯,但是我們現(xiàn)在沒有使用x509的證書啊,所以我們需要讓他跳過安全認(rèn)證
3. 帶上參數(shù)再次嘗試
[root@node1 pki]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" get pod --insecure-skip-tls-verify=true -n zhangsan
Error from server (Forbidden): pods is forbidden: User "jerry" cannot list resource "pods" in API group "" in the namespace "zhangsan"
現(xiàn)在我們再來看,他報的錯是不是跟剛剛不一樣了,這個報錯說的是jerry這個用戶沒有權(quán)限
能看到這個其實(shí)就說明我們已經(jīng)可以登錄了,只是沒有權(quán)限看到一些信息罷了
2. 角色授權(quán)
上面我們提到了用戶的登錄,提到了一點(diǎn)點(diǎn)授權(quán),現(xiàn)在開始聊授權(quán)的那些事
默認(rèn)情況下k8s采用的是Node和RBAC的鑒權(quán)模式
RBAC就是基于角色的訪問控制 R就是role嘛
我們可以在kube-apiserver文件里面看到
spec:
containers:
- command:
- kube-apiserver
- --token-auth-file=/etc/kubernetes/pki/jerry.csv
- --advertise-address=192.168.200.200
- --allow-privileged=true
# 就是這一行
- --authorization-mode=Node,RBAC
剛剛我們不是使用jerry用戶登錄但是沒有任何權(quán)限嗎?我們現(xiàn)在將這一行參數(shù)改掉
# 將之前的注釋掉,然后寫一行新的
# - --authorization-mode=Node,RBAC
# 這個是總是允許,不會鑒權(quán),你能登錄就有權(quán)限,這個模式僅用于測試
- --authorization-mode=AlwaysAllow
# 重啟kubelet
[root@master manifests]# systemctl restart kubelet
然后我們來到node節(jié)點(diǎn)再嘗試一下jerry用戶
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" get pod --insecure-skip-tls-verify=true -n zhangsan
NAME READY STATUS RESTARTS AGE
test01 1/1 Running 0 56m
我們發(fā)現(xiàn)他確實(shí)有權(quán)限查看了,好了但是我們的重點(diǎn)并不是這個,我們將他改回來
role與rolebinding
是通過命名空間來授權(quán)的,你在哪個命名空間創(chuàng)建的角色,那么這個角色只有這個命名空間下的權(quán)限
rolebinding就是將角色與用戶進(jìn)行綁定
1. 創(chuàng)建角色
剛剛我們不是有一個Jerry用戶可以登錄集群,但是沒有任何權(quán)限嗎?
那我們現(xiàn)在來授權(quán)
# 不知道參數(shù)是怎么來的可以使用kubectl create role --help 里面有示例
[root@master role]# kubectl create role jerry --verb=get --verb=list --verb=watch --resource=pods --dry-run=client -o yaml > jerry.yaml
[root@master role]# kubectl apply -f jerry.yaml
role.rbac.authorization.k8s.io/jerry created
[root@master role]# kubectl get role
NAME CREATED AT
jerry 2024-02-20T09:31:35Z
pod-reader 2024-02-20T05:23:30Z
我們現(xiàn)在有2個role一個是之前的,一個jerry就是剛剛我們創(chuàng)建出來的
現(xiàn)在我們角色有了,但是jerry用戶依舊是查不到任何信息的,因?yàn)槲覀儧]有對他進(jìn)行綁定
2. rolebinding
# 注意一個坑,當(dāng)這個用戶是token登錄的時候必須指定他的token,老版本不會有這個問題,新版本不指定的話依然是沒有權(quán)限的,注意一下
[root@master role]# kubectl create rolebinding jerry --role=jerry --user=jerry --token="3127c2e2b863d4c23878a" --dry-run=client -o yaml > rolebinding.yaml
[root@master role]# kubectl apply -f rolebinding.yaml
rolebinding.rbac.authorization.k8s.io/jerry created
[root@master role]# kubectl get rolebindings.rbac.authorization.k8s.io
NAME ROLE AGE
jerry Role/jerry 5s
zhangsan Role/pod-reader 4h3m
這里的每一步操作都應(yīng)該能看懂吧,然后我們回到node節(jié)點(diǎn)上使用jerry來查一下zhangsan命名空間下的pod
3. 驗(yàn)證權(quán)限
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" get pod --insecure-skip-tls-verify=true -n zhangsan
NAME READY STATUS RESTARTS AGE
test01 1/1 Running 0 4h24m
我們可以看到,他現(xiàn)在就可以看到pod的信息了,但是我們在指定權(quán)限的時候是沒有給他創(chuàng)建的權(quán)限的,那么他肯定不能創(chuàng)建pod,但是我們現(xiàn)在想要他可以創(chuàng)建pod怎么辦呢?
也是很簡單,只需要給角色加上一個權(quán)限就可以了
4. 修改權(quán)限
修改權(quán)限我們只需要修改jerry.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: jerry
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
# 加上這個他就可以創(chuàng)建pod了,如果加上delete那么他就可以刪除
- create
然后我們再apply這個文件
[root@master role]# kubectl apply -f jerry.yaml
role.rbac.authorization.k8s.io/jerry configured
5. 驗(yàn)證是否成功增加權(quán)限
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" --insecure-skip-tls-verify=true -n zhangsan run test02 --image nginx
pod/test02 created
我們可以看到pod被創(chuàng)建出來了,說明剛剛的權(quán)限已經(jīng)增加上了
這里我們僅僅只是針對pod的操作,如果我要創(chuàng)建一個deployment控制器呢?
上操作
6. deploymentde的操作
我們仔細(xì)觀察一下jerry.yaml這個文件,發(fā)現(xiàn)里面有一行寫的是pods,那我們是不是直接在這里加上deployments就好了呢?
我們來試試
# 修改yaml文件
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: jerry
rules:
- apiGroups:
- ""
resources:
- pods
- deployments
verbs:
- get
- list
- watch
- create
然后我們apply這個文件
[root@master role]# kubectl apply -f jerry.yaml
role.rbac.authorization.k8s.io/jerry configured
我們來看看是不是能夠創(chuàng)建deployment了
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" --insecure-skip-tls-verify=true -n zhangsan create deployment test03 --image nginx
error: failed to create deployment: deployments.apps is forbidden: User "jerry" cannot create resource "deployments" in API group "apps" in the namespace "zhangsan"
喔嚯,報錯了,我們不是加上了deployment嗎?
這其實(shí)是因?yàn)槲覀冞€需要給他指定apiGroup,光指定資源是不行的,能創(chuàng)建pod是因?yàn)閜od他的apiVersion就是v1,而deployment的apiVersion是apps/v1所以他會報錯,那我們再來修改一下文件
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: jerry
rules:
- apiGroups:
- ""
# 加上這個,如果你想要創(chuàng)建其他的資源,那么你也要在這里寫上
# 查詢apiVersion很簡單,你可以使用kubectl create xxx --dry-run 的方式,也可以直接 kubectl api-version去查,查到之后填到這里
- "apps"
resources:
- pods
- deployments
verbs:
- get
- list
- watch
- create
然后我們apply之后再來創(chuàng)建
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" --insecure-skip-tls-verify=true -n zhangsan create deployment test03 --image nginx
deployment.apps/test03 created
我們現(xiàn)在是可以創(chuàng)建deployment了,那我們想更新他的副本數(shù)量也是可以的嘛?來看看
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" --insecure-skip-tls-verify=true -n zhangsan scale deployment test03 --replicas 3
Error from server (Forbidden): deployments.apps "test03" is forbidden: User "jerry" cannot patch resource "deployments/scale" in API group "apps" in the namespace "zhangsan"
他又報錯了,他說不能patch,那我們在verb里面加上個試試看呢,等一下,注意看完報錯,他說resource里面是deployments/scale我們好像也沒有給他這個資源,一并加上
最終的yaml文件是這樣的
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: jerry
rules:
- apiGroups:
- ""
- "apps"
resources:
- pods
- deployments/scale
- deployments
verbs:
- get
- patch
- list
- watch
- create
我們apply之后再來試試看呢
[root@master role]# kubectl apply -f jerry.yaml
role.rbac.authorization.k8s.io/jerry configured
# 修改副本數(shù)
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="3127c2e2b863d4c23878a" --insecure-skip-tls-verify=true -n zhangsan scale deployment test03 --replicas 3
deployment.apps/test03 scaled
我們可以看到現(xiàn)在他可以了
這個yaml文件還可以有另外一種格式
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: jerry
rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments"]
verbs: ["get","delete","watch"]
這種方式也可以,喜歡用哪種就用哪種,無所謂的嘛
這個就是role和rolebinding
clusterrole和clusterrolebinding
clusterrole對于role來說,role是屬于某個命名空間的,而clusterrole是屬于整個集群的,clusterrole可以進(jìn)行clusterrolebinding,也可以進(jìn)行rolebinding,rolebinding的時候指定一下命名空間就可以了
使用rolebinding的時候它就相當(dāng)于是將clusterrole的權(quán)限模板給了某個命名空間下的某個用戶,也就是說在你進(jìn)行rolebinding的時候你就當(dāng)這個clusterrole就是一個普通的沒有指定特定命名空間的role
我們可以這樣想一下,我們有很多個命名空間,然后每個命名空間里的用戶權(quán)限其實(shí)都是差不多的,那么如果我要是使用role的話,我就需要每個命名空間下都要去創(chuàng)建role,費(fèi)時費(fèi)力
但是我們使用clusterrole的話,所有命名空間都可以看到這個clusterrole,那么就無需每個命名空間都去創(chuàng)建role了,直接rolebingding就好了
1. 創(chuàng)建一個新的用戶,使用token
[root@master pki]# openssl rand -hex 10 >> /etc/kubernetes/pki/jerry.csv
[root@master pki]# cat jerry.csv
# 這里的token不一樣長可能是因?yàn)槲野碼插入的時候多按了一下,沒什么太大的問題,token是可以自己寫的
3127c2e2b863d4c23878a,jerry,2000
958a15cfa9431e088e0b,tom,2001
2. 創(chuàng)建clusterrole
這個創(chuàng)建方法與role是一樣的
[root@master role]# kubectl create clusterrole cluster-pod --verb=get,list,watch --resource=pods --dry-run=client -o yaml > clusterrole.yaml
[root@master role]# cat clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: cluster-pod
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
3. clusterrolebinding
[root@master role]# kubectl create clusterrolebinding cluster-tom --clusterrole=cluster-pod --user=tom --token="958a15cfa9431e088e0b"
4. 驗(yàn)證權(quán)限
在驗(yàn)證權(quán)限之前我建議退出shell重新登錄一下,或者重啟一下節(jié)點(diǎn),因?yàn)槟阒苯拥卿浀脑捤赡軙箦e
error: You must be logged in to the server (Unauthorized)
我就遇到這個問題了,我的解決方式是將kube-system里面的apiserver這個pod重啟了
# 查看pod
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="958a15cfa9431e088e0bb" --insecure-skip-tls-verify=true -n zhangsan get pods
NAME READY STATUS RESTARTS AGE
test01 1/1 Running 0 6h29m
test03-6484c64bb6-88xlr 1/1 Running 0 81m
test03-6484c64bb6-9hf4l 1/1 Running 0 75m
test03-6484c64bb6-w4zwk 1/1 Running 0 75m
# 查看其他命名空間的pod
[root@node1 manifests]# kubectl --server="https://192.168.200.200:6443" --token="958a15cfa9431e088e0bb" --insecure-skip-tls-verify=true -n kube-system get pods
NAME READY STATUS RESTARTS AGE
coredns-5bbd96d687-9tsbb 1/1 Running 38 (7h6m ago) 42d
coredns-5bbd96d687-q6dl8 1/1 Running 38 (7h6m ago) 42d
etcd-master 1/1 Running 42 (7h6m ago) 44d
kube-apiserver-master 1/1 Running 0 13m
kube-controller-manager-master 1/1 Running 63 (3h1m ago) 44d
kube-proxy-mp98s 1/1 Running 40 (7h6m ago) 44d
kube-proxy-snk8k 1/1 Running 46 (7h6m ago) 44d
kube-proxy-xmxpj 1/1 Running 38 (7h6m ago) 44d
kube-scheduler-master 1/1 Running 61 (3h1m ago) 44d
metrics-server-54b5b8fb6-v4cqx 1/1 Running 29 (7h4m ago) 7d1h
我們可以看到,他可以看到其他命名空間下的pod,這就是role和clusterrole的區(qū)別了
至于他能不能創(chuàng)建pod,能不能創(chuàng)建deployment,這些東西就是跟role是一樣的了
鏈接:https://www.cnblogs.com/fsdstudy/p/18023589
(版權(quán)歸原作者所有,侵刪)
