k8s-權(quán)限管理

1. 身份認(rèn)證

我們?cè)谀壳暗膋8s集群環(huán)境里面，只能在master節(jié)點(diǎn)上執(zhí)行kubectl的一些命令，在其他節(jié)點(diǎn)上執(zhí)行就會(huì)報(bào)錯(cuò)

|   |   |
| --- | --- |
|   |# 看一下是不是 |
|   | [root@node1 ~]# kubectl get nodes |
|   | E0220 1215.695133  6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1] connect: connection refused |
|   | E0220 1215.695771  6091 memcache.go:238] couldn't get current server API group list: Get"http://localhost:8080/api?timeout=32s": dial tcp [::1] connect: connection refused |
|   | E0220 1215.697555  6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1] connect: connection refused |
|   | E0220 1215.699191  6091 memcache.go:238] couldn't get current server API group list: Get"http://localhost:8080/api?timeout=32s": dial tcp [::1] connect: connection refused |
|   | E0220 1215.700655  6091 memcache.go:238] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1] 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都會(huì)報(bào)錯(cuò)，那就更不談創(chuàng)建pod之類的操作了，那為什么master可以而其他節(jié)點(diǎn)不行呢？
這是因?yàn)樵趍aster節(jié)點(diǎn)上是有一個(gè)kubeconfig的

|   |   |
| --- | --- |
|   | [root@master ~]#env|grep -i kubeconfig |
|   | KUBECONFIG=/etc/kubernetes/admin.conf |

我們可以看到在master節(jié)點(diǎn)上是有一個(gè)環(huán)境變量加載了這個(gè)admin.conf這個(gè)文件的，這個(gè)文件就是k8s集群默認(rèn)的管理員文件，換一種說(shuō)法，只要你有本事偷走這個(gè)文件并且保障你的網(wǎng)絡(luò)跟這個(gè)集群的網(wǎng)絡(luò)是通的，那么恭喜你，得到了一個(gè)k8s集群

node節(jié)點(diǎn)操作

我們現(xiàn)在來(lái)將這個(gè)admin.conf傳到node1上，再來(lái)看看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 |

我們通過(guò)這個(gè)小實(shí)驗(yàn)看到，node1節(jié)點(diǎn)確實(shí)是可以獲取到節(jié)點(diǎn)信息了，但是他執(zhí)行的命令跟master上有所不同，在node1上執(zhí)行的時(shí)候他是需要執(zhí)行配置文件的，如果你不想執(zhí)行的話可以將這個(gè)注冊(cè)到環(huán)境變量里面

|   |   |
| --- | --- |
|   | [root@node1 ~]#echo"export KUBECONFIG=/root/admin.conf">> /etc/profile |
|   | [root@node1 ~]#tail-1 /etc/profile |
|   |exportKUBECONFIG=/root/admin.conf |

只需要這樣就好了

但是這樣存在一個(gè)問(wèn)題，他們用的都是管理員的配置文件，那么就相當(dāng)于他們都是管理員，對(duì)集群有全部權(quán)限，我們追求是的最小權(quán)限原則，就是我給你的權(quán)限正好能夠讓你完成屬于你自己的任務(wù)，多的權(quán)限不應(yīng)該有，那么我們能不能像Linux一樣創(chuàng)建普通用戶，給普通用戶定制權(quán)限呢？當(dāng)然是可以的

創(chuàng)建普通用戶并授權(quán)

我們現(xiàn)在來(lái)創(chuàng)建一個(gè)普通用戶zhangsan并授權(quán)

1. 生成私鑰

|   |   |
| --- | --- |
|   |# 使用openssl生成一個(gè)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用戶證書請(qǐng)求文件

|   |   |
| --- | --- |
|   |# 使用client.key 生成一個(gè)新的文件叫做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用戶如何將請(qǐng)求發(fā)送給k8s的ca進(jìn)行證書頒發(fā)呢？這個(gè)時(shí)候我們可以使用k8s自帶的ca來(lái)頒發(fā)證書

|   |   |
| --- | --- |
|   |# k8s的ca在/etc/kubernetes/pki下 |
|   | [root@master ca]# openssl x509 -req -inclient.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 |
|   |# 切到這個(gè)命名空間 |
|   | [root@master ca]# kubectl config set-context --current --namespace zhangsan |
|   | Context"kubernetes-admin@kubernetes"modified. |
|   |# 創(chuàng)建一個(gè)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個(gè)權(quán)限，用戶用張三，李四，王五，那我們現(xiàn)在給他們授權(quán)的話只能是一個(gè)權(quán)限一個(gè)權(quán)限的去給，萬(wàn)一后面又新增了用戶我們依舊是一個(gè)個(gè)去指定，過(guò)于麻煩，而角色就是介于權(quán)限與用戶之間的一個(gè)模板，就像這樣
我們指定了一個(gè)角色是管理員，擁有增刪改查4個(gè)權(quán)限
一個(gè)是開發(fā)的角色，擁有增改查的權(quán)限
一個(gè)是普通用戶角色，只有查的權(quán)限
我們指定好這3個(gè)模板之后，后面新來(lái)的用戶只需要知道他的作用是什么，比如他就是一個(gè)普通用戶，那我們直接把這個(gè)模板給他套上，那他就只有查的權(quán)限，來(lái)了一個(gè)開發(fā)者，那我們就給他開發(fā)的這個(gè)角色模板，他就自然而然的擁有增改查的權(quán)限

|   |   |
| --- | --- |
|   |# 這里的pod-reader是role的名字 后面的--verb就是這個(gè)角色所包含哪些權(quán)限，并且這個(gè)角色所能操作的資源對(duì)象僅僅只有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)建一個(gè)rolebinding名字叫zhangsan，這個(gè)zhangsan并不是用戶張三，而是這個(gè)rolebinding的名字，后面--user這個(gè)才是用戶張三 |
|   | [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)于這個(gè)文件的框架，我們可以到官網(wǎng)去找到

地址 https://kubernetes.io/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/
在官網(wǎng)找到之后我們只需要做一些修改就行,改成這樣就可以，直接復(fù)制這個(gè)去改也行

|  |  |
|---|---|
|  |apiVersion:v1|
|  |kind:Config|
|  |  |
|  |clusters:|
|  |-cluster:|
|  |name:cluster-zs|
|  |  |
|  |users:|
|  |-name:zhangsan|
|  |  |
|  |contexts:|
|  |-context:|
|  |name:context-zs|
|  |namespace:zhangsan|
|  |current-context:"context-zs"|

這個(gè)文件就寫好了，但是目前來(lái)看他與管理員的那個(gè)admin.conf好像不一樣，那個(gè)文件里面內(nèi)容很多，這個(gè)很少
這是因?yàn)槲覀冞€沒(méi)有將剛剛創(chuàng)建出來(lái)的那些密鑰文件嵌入進(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個(gè)操作搞定之后，你再去看看這個(gè)文件，你會(huì)發(fā)現(xiàn)他跟admin.conf是一樣一樣的了

9. 驗(yàn)證權(quán)限

這個(gè)文件我們就算搞定了，我們來(lái)看看使用這個(gè)文件所擁有的權(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"inAPI group""inthe namespace"zhangsan"|
|   |# 我們看報(bào)錯(cuò)信息，用戶zhangsan是不能創(chuàng)建的，我們來(lái)看看除了pod之外的其他資源是否可見(jiàn) |
|   | [root@node1 ~]# kubectl get ns --kubeconfig=kube-zhangsan |
|   | Error from server (Forbidden): namespaces is forbidden: User"zhangsan"cannot list resource"namespaces"inAPI group""at the cluster scope |

現(xiàn)在這個(gè)文件符合我們預(yù)期的權(quán)限，那么這就是創(chuàng)建一個(gè)用戶并授權(quán)的過(guò)程

靜態(tài)token登錄

這個(gè)方法用人話來(lái)講就是，賬號(hào)密碼登錄
靜態(tài)的方式就是創(chuàng)建一個(gè)csv文件，csv文件的格式是
token,user,id
token這一欄我們可以使用openssl生成

1. 生成token

|   |   |
| --- | --- |
|   |# 注意文件位置，最好放在/etc/kubernetes/pki下，因?yàn)閗8s默認(rèn)只對(duì)/etc/kubernetes這個(gè)目錄有權(quán)限操作，放在其他位置可能會(huì)產(chǎn)生權(quán)限錯(cuò)誤 |
|   | [root@master pki]# openssl rand -hex 10 > jerry.csv |
|   | [root@master pki]#catjerry.csv |
|   |# 這里的用戶名和id可以自己改動(dòng) |
|   | 3127c2e2b863d4c23878a,jerry,2000 |

在apiserver加入?yún)?shù)

|   |   |
| --- | --- |
|   |# 默認(rèn)情況下你剛剛寫的文件與集群是沒(méi)有任何關(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后面就是你剛剛的那個(gè)文件 |
|   | - --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 |

他會(huì)有一個(gè)報(bào)錯(cuò)，但是我們現(xiàn)在沒(méi)有使用x509的證書啊，所以我們需要讓他跳過(guò)安全認(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"inAPI group""inthe namespace"zhangsan"|

現(xiàn)在我們?cè)賮?lái)看，他報(bào)的錯(cuò)是不是跟剛剛不一樣了，這個(gè)報(bào)錯(cuò)說(shuō)的是jerry這個(gè)用戶沒(méi)有權(quán)限
能看到這個(gè)其實(shí)就說(shuō)明我們已經(jīng)可以登錄了，只是沒(méi)有權(quán)限看到一些信息罷了

2. 角色授權(quán)

上面我們提到了用戶的登錄，提到了一點(diǎn)點(diǎn)授權(quán)，現(xiàn)在開始聊授權(quán)的那些事
默認(rèn)情況下k8s采用的是Node和RBAC的鑒權(quán)模式
RBAC就是基于角色的訪問(wèn)控制 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用戶登錄但是沒(méi)有任何權(quán)限嗎？我們現(xiàn)在將這一行參數(shù)改掉

|   |   |
| --- | --- |
|   |# 將之前的注釋掉，然后寫一行新的 |
|   |# - --authorization-mode=Node,RBAC |
|   |# 這個(gè)是總是允許，不會(huì)鑒權(quán)，你能登錄就有權(quán)限，這個(gè)模式僅用于測(cè)試 |
|   | - --authorization-mode=AlwaysAllow |
|   |# 重啟kubelet |
|   | [root@master manifests]# systemctl restart kubelet |

然后我們來(lái)到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)并不是這個(gè)，我們將他改回來(lái)

role與rolebinding

是通過(guò)命名空間來(lái)授權(quán)的，你在哪個(gè)命名空間創(chuàng)建的角色，那么這個(gè)角色只有這個(gè)命名空間下的權(quán)限
rolebinding就是將角色與用戶進(jìn)行綁定

1. 創(chuàng)建角色

剛剛我們不是有一個(gè)Jerry用戶可以登錄集群，但是沒(méi)有任何權(quán)限嗎？
那我們現(xiàn)在來(lái)授權(quán)

|   |   |
| --- | --- |
|   |# 不知道參數(shù)是怎么來(lái)的可以使用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-20T0935Z |
|   | pod-reader  2024-02-20T0530Z |

我們現(xiàn)在有2個(gè)role一個(gè)是之前的，一個(gè)jerry就是剛剛我們創(chuàng)建出來(lái)的
現(xiàn)在我們角色有了，但是jerry用戶依舊是查不到任何信息的，因?yàn)槲覀儧](méi)有對(duì)他進(jìn)行綁定

2. rolebinding

|   |   |
| --- | --- |
|   |# 注意一個(gè)坑，當(dāng)這個(gè)用戶是token登錄的時(shí)候必須指定他的token，老版本不會(huì)有這個(gè)問(wèn)題，新版本不指定的話依然是沒(méi)有權(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來(lái)查一下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的信息了，但是我們?cè)谥付?quán)限的時(shí)候是沒(méi)有給他創(chuàng)建的權(quán)限的，那么他肯定不能創(chuàng)建pod，但是我們現(xiàn)在想要他可以創(chuàng)建pod怎么辦呢？
也是很簡(jiǎn)單，只需要給角色加上一個(gè)權(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|
|  |# 加上這個(gè)他就可以創(chuàng)建pod了，如果加上delete那么他就可以刪除 |
|  |-create|

然后我們?cè)賏pply這個(gè)文件

|   |   |
| --- | --- |
|   | [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)建出來(lái)了，說(shuō)明剛剛的權(quán)限已經(jīng)增加上了
這里我們僅僅只是針對(duì)pod的操作，如果我要?jiǎng)?chuàng)建一個(gè)deployment控制器呢？
上操作

6. deploymentde的操作

我們仔細(xì)觀察一下jerry.yaml這個(gè)文件，發(fā)現(xiàn)里面有一行寫的是pods，那我們是不是直接在這里加上deployments就好了呢？
我們來(lái)試試

|  |  |
|---|---|
|  |# 修改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這個(gè)文件

|   |   |
| --- | --- |
|   | [root@master role]# kubectl apply -f jerry.yaml |
|   | role.rbac.authorization.k8s.io/jerry configured |

我們來(lái)看看是不是能夠創(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"inAPI group"apps"inthe namespace"zhangsan"|

喔嚯，報(bào)錯(cuò)了，我們不是加上了deployment嗎？
這其實(shí)是因?yàn)槲覀冞€需要給他指定apiGroup，光指定資源是不行的，能創(chuàng)建pod是因?yàn)閜od他的apiVersion就是v1，而deployment的apiVersion是apps/v1所以他會(huì)報(bào)錯(cuò)，那我們?cè)賮?lái)修改一下文件

|  |  |
|---|---|
|  |apiVersion:rbac.authorization.k8s.io/v1|
|  |kind:Role|
|  |metadata:|
|  |creationTimestamp:null|
|  |name:jerry|
|  |rules:|
|  |-apiGroups:|
|  |-""|
|  |# 加上這個(gè)，如果你想要?jiǎng)?chuàng)建其他的資源，那么你也要在這里寫上 |
|  |# 查詢apiVersion很簡(jiǎn)單，你可以使用kubectl create xxx --dry-run 的方式，也可以直接 kubectl api-version去查，查到之后填到這里 |
|  |-"apps"|
|  |resources:|
|  |-pods|
|  |-deployments|
|  |verbs:|
|  |-get|
|  |-list|
|  |-watch|
|  |-create|

然后我們apply之后再來(lái)創(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ù)量也是可以的嘛？來(lái)看看

|   |   |
| --- | --- |
|   | [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"inAPI group"apps"inthe namespace"zhangsan"|

他又報(bào)錯(cuò)了，他說(shuō)不能patch，那我們?cè)趘erb里面加上個(gè)試試看呢，等一下，注意看完報(bào)錯(cuò)，他說(shuō)resource里面是deployments/scale我們好像也沒(méi)有給他這個(gè)資源，一并加上
最終的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之后再來(lái)試試看呢

|   |   |
| --- | --- |
|   | [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)在他可以了
這個(gè)yaml文件還可以有另外一種格式

|  |  |
|---|---|
|  |apiVersion:rbac.authorization.k8s.io/v1|
|  |kind:Role|
|  |metadata:|
|  |creationTimestamp:null|
|  |name:jerry|
|  |rules:|
|  |-apiGroups:["","apps"]|
|  |resources:["pods","deployments"]|
|  |verbs:["get","delete","watch"]|

這種方式也可以，喜歡用哪種就用哪種，無(wú)所謂的嘛
這個(gè)就是role和rolebinding

clusterrole和clusterrolebinding

clusterrole對(duì)于role來(lái)說(shuō)，role是屬于某個(gè)命名空間的，而clusterrole是屬于整個(gè)集群的，clusterrole可以進(jìn)行clusterrolebinding，也可以進(jìn)行rolebinding，rolebinding的時(shí)候指定一下命名空間就可以了
使用rolebinding的時(shí)候它就相當(dāng)于是將clusterrole的權(quán)限模板給了某個(gè)命名空間下的某個(gè)用戶，也就是說(shuō)在你進(jìn)行rolebinding的時(shí)候你就當(dāng)這個(gè)clusterrole就是一個(gè)普通的沒(méi)有指定特定命名空間的role
我們可以這樣想一下，我們有很多個(gè)命名空間，然后每個(gè)命名空間里的用戶權(quán)限其實(shí)都是差不多的，那么如果我要是使用role的話，我就需要每個(gè)命名空間下都要去創(chuàng)建role，費(fèi)時(shí)費(fèi)力
但是我們使用clusterrole的話，所有命名空間都可以看到這個(gè)clusterrole，那么就無(wú)需每個(gè)命名空間都去創(chuàng)建role了，直接rolebingding就好了

1. 創(chuàng)建一個(gè)新的用戶，使用token

|   |   |
| --- | --- |
|   | [root@master pki]# openssl rand -hex 10 >> /etc/kubernetes/pki/jerry.csv |
|   | [root@master pki]#catjerry.csv |
|   |# 這里的token不一樣長(zhǎng)可能是因?yàn)槲野碼插入的時(shí)候多按了一下，沒(méi)什么太大的問(wèn)題，token是可以自己寫的 |
|   | 3127c2e2b863d4c23878a,jerry,2000 |
|   | 958a15cfa9431e088e0b,tom,2001 |

2. 創(chuàng)建clusterrole

這個(gè)創(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]#catclusterrole.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)槟阒苯拥卿浀脑捤赡軙?huì)報(bào)錯(cuò)
error: You must be logged in to the server (Unauthorized)
我就遇到這個(gè)問(wèn)題了，我的解決方式是將kube-system里面的apiserver這個(gè)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