Kubernetes RBAC角色權限控制

摘選:https://i4t.com/4448.html

在Kubernetes中所有的API對象都保存在ETCD裡，可是，對這些API對象的操作，卻一定是通過訪問kube-apiserver實現的。我們需要APIServer來幫助我們授權工作，而在Kubernetes項目中，負責完成

RBAC是基於角色的訪問控制 (Role-Based Access Control) 在RBAC中，權限與角色相關聯。Kubernetes 基於角色的訪問控制使用rbac.authorization.k8s.io API組來實現權限控制，RBAC允許管理員通過Kubernetes API動態的配置權限策略。如果需要開啟RBAC授權需要在apiserver組件中指定--authorization-mode=Node,RBAC

修改完畢後需要重啟apiserver，在我提供的二進制安裝已經將下面參數添加進去。如果使用的是kubeadm安裝在1.6版本默認已經啟用了RBAC

這裡我們需要明確三個RBAC最基本的概念

• Role: 角色，它定義了一組規則，定義了一組對Kubernetes API對象的操作權限
• Subject: 被作用者，既可以是"人"，也可以是機器，當然也可以是我們Kubernetes中定義的用戶(ServiceAccount主要負責kubernetes內置用戶)
• RoleBinding: 定義了"被作用者"和"角色"的綁定關係

RBAC API對象

• Pods
• ConfigMaps
• Deployments
• Nodes
• Secrets
• Namespaces

資源對象可能存在的操作有如下

• create
• get
• delete
• list
• update
• edit
• watch
• exec

這些資源和API Group進行關聯，比如Pods屬於Core API Group，而Deployment屬於apps API Group，要在kubernetes中進行RBAC授權

Role && Rolebinding

實際上，Role本身就是一個Kubernetes的API對象，定義文件如下

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: mynamespace
 name: example-role
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]

文件解釋
首先，Role對象指定了它能產生作用的Namespace(mynamespace)。Namespace是kubernetes項目中的一個邏輯管理單位。不同Namespace的API對象，在通過kubectl命令進行操作的時候，是互相隔離的

namespace並不會提供任何實際的隔離或者多租戶能力，如果沒有設置namespace默認則是default

rules字段定義它的是權限規則，這條規則的含義就是允許"被作用者"，對namespace下面pod (resources中定義)有哪些權限

用戶的權限對應的API資源對象已經創建了，但是還沒有綁定。也就是隻有一個規則沒有規定哪些用戶使用這個權限

這裡進行Rolebinding介紹

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: example-rolebinding
 namespace: mynamespace
subjects:
- kind: User
 name: example-user
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: example-role
 apiGroup: rbac.authorization.k8s.io

在Rolebinding中定義了一個subject字段，即"被作用者"。它的類型是User，即Kubernetes裡的用戶，名稱為example-user

在kubernetes裡的User，也就是用戶，只是一個授權系統裡的邏輯概念。它需要通過外部認證服務，比如Keystone，來提供。或者直接給APIServer指定一個用戶名、密碼文件。那麼kubernetes的授權系統就能夠從這個文件裡找到對象的用戶

Rolebinding對象通過roleRef字段可以直接通過名字，來引用前面定義的Role對象(example-role)，從而定義了"被作用者(Subject)"和"角色(Role)"之間的綁定關係

Role和RoleBinding 他們的權限限制規則僅僅在他們自己的namespace內有效，roleRef也只能引用當前namespace裡的Role對象

ClusterRole && ClusterRoleBinding

對於某一個role想要作用的namespace的時候，就必須需要使用ClusterRole和ClusterRoleBinding兩個組合。這兩個API 對象的用法跟Role和Rolebinding完全一樣

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: example-clusterrole
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]

###############################################
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: example-clusterrolebinding
subjects:
- kind: User
 name: example-user
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: example-clusterrole
 apiGroup: rbac.authorization.k8s.io

在上面的例子中，ClusterRole和ClusterRoleBinding的組合，意味著名叫example-user的用戶，擁有對所有namespace裡的Pod進行Get、Watch、List操作的權限。

類似的，Role對象的rules字段也可以進一步細化，可以只針對某一個具體權限對象進行設置

rules:
- apiGroups: [""]
 resources: ["configmaps"]
 resourceNames: ["my-config"]
 verbs: ["get"]

上面的例子表示，這條規則的"被作用者"，只對my-config的configmap對象有權限進行get操作

前面也說過，在Kubernetes中已經內置了很多個位系統保留的

#我們可以通過下面的命令獲取到
[root@abcdocker sa-test]# kubectl get clusterroles
NAME AGE
admin 93d
approve-node-server-renewal-csr 93d
cluster-admin 93d
edit 93d
...
system:public-info-viewer 93d
system:volume-scheduler 93d
traefik-ingress-controller 45d
view 93d

此外，Kubernetes還提供了四個預先定義好的ClusterRole來提供用戶直接使用

• cluster-admin
• admin
• edit
• view

其中cluster-admin角色，對應的是整個Kubernetes項目中最高權限(verbs=*)

#我們可以通過下面的命令查看clusterrole的權限
[root@abcdocker sa-test]# kubectl describe clusterrole cluster-admin -n kube-system
Name: cluster-admin
Labels: kubernetes.io/bootstrapping=rbac-defaults
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
 Resources Non-Resource URLs Resource Names Verbs 

 --------- ----------------- -------------- -----
 *.* [] [] [*]
 [*] [] [*]

ServiceAccount

前面所介紹的大多數不使用，ServiceAccount主要負責kubernetes內置用戶，下面簡單定義一個ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
 namespace: mynamespace
 name: example-sa

我們定義了一個serverAccount對象，只需要name以及namespace最基礎字段就可以。然後通過編寫rolebinding的yaml文件，來為這個serviceAccount分配權限

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: example-rolebinding
 namespace: mynamespace
subjects:
- kind: ServiceAccount
 name: example-sa
 namespace: mynamespace
roleRef:
 kind: Role
 name: example-role
 apiGroup: rbac.authorization.k8s.io

在Rolebinding對象裡，subject字段的類型(kind)，不在是一個User，而是一個名叫example-sa的ServerAccount。而roleRef引用的Role對象，依然名叫example-role。也就是我們上面定義的

#yaml文件如下
[root@abcdocker serveraccount]# cat pod-sa.yaml
apiVersion: v1
kind: Pod
metadata:
 namespace: mynamespace
 name: sa-token-test
spec:
 containers:
 - name: nginx
 image: nginx:1.7.9
 serviceAccountName: example-sa


[root@abcdocker serveraccount]# cat role-binding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: example-rolebinding
 namespace: mynamespace
subjects:
- kind: ServiceAccount
 name: example-sa
 namespace: mynamespace
roleRef:
 kind: Role
 name: example-role
 apiGroup: rbac.authorization.k8s.io


[root@abcdocker serveraccount]# cat role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: mynamespace
 name: example-role
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]


[root@abcdocker serveraccount]# cat role-binding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata: 

 name: example-rolebinding
 namespace: mynamespace
subjects:
- kind: ServiceAccount
 name: example-sa
 namespace: mynamespace
roleRef:
 kind: Role
 name: example-role
 apiGroup: rbac.authorization.k8s.io


#接下來我們創建命名空間
[root@abcdocker serveraccount]# kubectl create namespace mynamespace
namespace/mynamespace created
[root@abcdocker serveraccount]# kubectl apply -f .
rolebinding.rbac.authorization.k8s.io/example-rolebinding created
role.rbac.authorization.k8s.io/example-role created
serviceaccount/example-sa created

[root@abcdocker serveraccount]# kubectl get sa -n mynamespace
NAME SECRETS AGE
default 1 26s
example-sa 1 22s

[root@abcdocker serveraccount]# kubectl get sa -n mynamespace example-sa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-sa","namespace":"mynamespace"}}
 creationTimestamp: "2019-11-28T08:01:22Z"
 name: example-sa
 namespace: mynamespace
 resourceVersion: "14579937"
 selfLink: /api/v1/namespaces/mynamespace/serviceaccounts/example-sa
 uid: 4481a40f-11b5-11ea-a57e-525400d7b284
secrets:
- name: example-sa-token-wms94

Kubernetes會為ServiceAccount自動創建一個Secret對象，即ServiceAccount定義最下面的secrets字段。其中，這裡的secret就是ServiceAccount對應來跟APIServer進行交互的授權文檔，一般為TOken，保存證書和密碼等，它以一個Secret對象保存在ETCD中

這時候我們就可以直接引用這個sa(serviceAccount)了

apiVersion: v1
kind: Pod
metadata:
 namespace: mynamespace
 name: sa-token-test
spec:
 containers:
 - name: nginx
 image: nginx
 serviceAccountName: example-sa

 #在最下面一行我們定義了一個名為example-sa

接下來我們可以通過describe查看pod狀態

[root@abcdocker serveraccount]# kubectl describe pod -n mynamespace sa-token-test
Name: sa-token-test
Namespace: mynamespace
...
 Mounts:
 /var/run/secrets/kubernetes.io/serviceaccount from example-sa-token-wms94 (ro)
...

ServiceAccount的token也就是secret對象是被Kubernetes自動掛載到了容器/var/run/secrets/kubernetes.io/serviceaccount目錄下

我們可以到Pod目錄進行查看

$ kubectl exec -it sa-token-test -n mynamespace -- /bin/bash
root@sa-token-test:/# ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt namespace token

在Kubernetes集群訪問主要是通過ca.crt來訪問Apiserver，更重要的是此時它只可以做GET、WATCH和LIST操作。因為example-sa這個ServiceAccount的權限已經被我們綁定了role限制

如果一個Pod沒有聲明sa，Kubernetes會自動在它的namespace創建一個名稱為default的默認ServiceAccount，然後分配給Pod。但是這種情況下默認ServiceAccount沒有關聯任何Role。也就是說它有APIServer的絕大多數權限

User && Group

Kubernetes除了有用戶(User)，還擁有用戶組(Group)概念，如果我們Kubernetes配置了外部認證服務的話，這個用戶組的概念就由外部認證服務提供

一個ServiceAccount在Kubernetes對應的用戶的名字是

system:serviceaccount:<serviceaccount>
/<serviceaccount>

而對應的用戶組則是

system:serviceaccounts:<namespace>
/<namespace>

比如，我們可以在RoleBinding中定義如下subjects

subjects:
- kind: Group
 name: system:serviceaccounts:mynamespace
 apiGroup: rbac.authorization.k8s.io

#這就意味著role的規則權限，作用於mynamespace裡的所有ServiceAccount，這就用到了用戶組的概念



subjects:
- kind: Group 

 name: system:serviceaccounts
 apiGroup: rbac.authorization.k8s.io

#這個role的規則權限，則作用於整個系統裡ServiceAccount

在Kubernetes中已經內置了很多歌為系統保留的ClusterRole，它們的名字都以system:開頭，可以使用kubectl get clusterroles查找到

現在我們可以理解，所謂的角色(Role)，其實就是一組規則權限列表，而我們分配這些權限的方式，就是通過創建RoleBinding對象，將被用者(subject)和權限列表綁定。

而對應的ClusterRole和ClusterRoleBinding，則是Kubernetes集群級別的Role和RoleBinding，它們不受namespace限制

一、創建一個只能訪問某個namespace的ServiceAccount

當我們創建一個sa之後，會自動幫我們創建一個secrets

[root@abcdocker ~]# kubectl create sa test-sa -n kube-system
serviceaccount/test-sa created

接下來可以查看一下sa

[root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
 creationTimestamp: "2019-11-28T09:32:54Z"
 name: test-sa 

 namespace: kube-system
 resourceVersion: "14590921"
 selfLink: /api/v1/namespaces/kube-system/serviceaccounts/test-sa
 uid: 0e218ad3-11c2-11ea-a57e-525400d7b284
secrets:
- name: test-sa-token-fs4fx

可以通過get secret查看

[root@abcdocker ~]# kubectl get secrets -n kube-system |grep test-sa-token
test-sa-token-fs4fx kubernetes.io/service-account-token 3 17h

我們需要創建一個role (角色)對象與sa進行關聯

#yaml文件如下
cat >>sa-role.yaml<apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: sa-role
 namespace: kube-system
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "list"]
- apiGroups: ["apps", "extensions"]
 resources: ["pods", "deployment", "replicasets"]
 verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
EOF
#這裡我們創建的role設置的權限是對pod有get和list權限，對deployment有下面其他權限


#執行文件yaml
[root@abcdocker ~]# kubectl apply -f sa-role.yaml
role.rbac.authorization.k8s.io/sa-role created

#檢查狀態
[root@abcdocker ~]# kubectl get role -n kube-system
NAME AGE
extension-apiserver-authentication-reader 93d
prometheus-k8s 15d
sa-role 9s 

...
#我們剛剛在kube-sytem下創建一個名稱為sa-role的role

角色創建完成之後我們就需要創建一個RoleBinding

cat >>sa-rolebinding.yaml<apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: sa-rolebinding
 namespace: kube-system
subjects:
- kind: ServiceAccount
 name: test-sa
 namespace: kube-system
roleRef:
 kind: Role
 name: sa-role
 apiGroup: rbac.authorization.k8s.io
EOF

#執行

[root@abcdocker ~]# kubectl apply -f sa-rolebinding.yaml
rolebinding.rbac.authorization.k8s.io/sa-rolebinding created

[root@abcdocker ~]# kubectl get rolebinding -n kube-system|grep sa
sa-rolebinding 28s

這時候我們創建的ServerAccount已經和我們role進行綁定了，通過rolebinding進行綁定。下面可以進行測試

#首先我們複製我們創建sa中secret裡面的token

[root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yaml
apiVersion: v1
kind: ServiceAccount 

metadata:
 creationTimestamp: "2019-11-28T09:32:54Z"
 name: test-sa
 namespace: kube-system
...
secrets:
- name: test-sa-token-fs4fx
#這個name為我們secret名稱，創建sa的時候會自動給我們創建secret


#接下來我們查看這個secret中的token
[root@abcdocker ~]# kubectl get secrets test-sa-token-fs4fx -n kube-system -o yaml
apiVersion: v1
data:
...
 namespace: a3ViZS1zeXN0ZW0=
 token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUowWlhOMExYTmhMWFJ2YTJWdUxXWnpOR1o0SWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWJtRnRaU0k2SW5SbGMzUXRjMkVpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1MWFXUWlPaUl3WlRJeE9HRmtNeTB4TVdNeUxURXhaV0V0WVRVM1pTMDFNalUwTURCa04ySXlPRFFpTENKemRXSWlPaUp6ZVhOMFpXMDZjMlZ5ZG1salpXRmpZMjkxYm5RNmEzVmlaUzF6ZVhOMFpXMDZkR1Z6ZEMxellTSjkuU04yRm0wemdiUi1XU21oVTdOYkxMWDZFRVNiSnNpNDNWRHZpOXJUdG1UcDVzSXl0RzJKNkFqUGNBeGxqSHE1dkdqVWNTTGpoOXd2aDBSV25HMXUydzZ3MHUtTGd0S0g3NllZNWVHRGVtSUxJaTcxeDZDNXlrTE85a3hNVU1sOG9WQmxnVGhFRVVrZEJjRk96X3pveEZCc1lGRV9xcm1NSGNma29RU0Y3UGRWSnp0VjBuYkZmem9fdWJ4cU5Zd2RaYzJIc2wyZ1VOT3NzcGRVdlV2ZXd6WGIwZzJwZnJ4NlVuUkpWU1FoSjJWbjdBWlFrXzJ6c0p2SXJPeXNLSlpJSm5RRlZFUGJCSXhIazNaR2o4WExjRUVEcmMySWRHUDNLcGFwdHlkU21hXzdXS1lmMFlQSThkdmZvZmdJcTlyUFd4YjRqeEg0NFFUZ0xtS1lHZ0VxR2x3
...

這裡我們複製token，使用bease64進行解密
echo "xxx" |base64 -d

6DF5431D-A1AD-4CB3-A554-9492D93ED0F4.png-832kB

現在token已經創建好了，我們使用dashboard進行演示

接下來我們打開dashboard的地址，將解密後的token複製進去

kubernetes dashboard建議使用火狐瀏覽器

77067D28-91C3-44AB-8472-B4C821EDBFCC.png-152.9kB

我們登陸到dashboard界面上，默認訪問的為default命名空間，因為我們授權的是kube-system空間，所以很多地方沒有權限。會有下面的報錯

FE3284DD-C4A9-4027-827C-BF76CB8898D1.png-645.5kB

在我們配置role的yaml文件中，只分配了pod和deployment以及replicasets相關權限，像pvc這種並沒有分配所以會提示firidden

我們將default修改為kube-system即可

085FB3C9-EDAF-4991-A498-24428243DC68.png-470.2kB

我們還可以直接通過rolebinding綁定系統提供的role權限

二、創建一個可以訪問所有namespace的ServiceAccount

上面創建單個namespace訪問權限主要是用了role和rolebinding，接下來我們使用clusterRole和ClusterRoleBinding進行演示。使用role和rolebinding只會綁定特定的namespace下，clusterRole會綁定到集群下

首先我們創建一個ServiceAccount對象

#這次我們不使用kubectl命令行創建，採用yaml的方式，關於sa的yaml定義格式可以參考上面的sa的介紹，並且我們將所有的配置文件寫在一個yaml中

cat >>sa.yaml<apiVersion: v1
kind: ServiceAccount
metadata:
 name: abcdocker-sa
 namespace: kube-system

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: abcdocker-clusterrolebinding #clusterrolebinding的名稱
subjects: #被作用者
- kind: ServiceAccount #類型
 name: abcdocker-sa #sa名稱
 namespace: kube-system #sa命名空間
roleRef: #角色引用
 kind: ClusterRole #類型為clusterRole
 name: cluster-admin #clust-admin為rbac系統最大權限
 apiGroup: rbac.authorization.k8s.io
#這裡的clusterRole我們直接使用系統內置的變量，我們直接創建clusterrolebinding就可以了
EOF


#接下來開始創建
[root@abcdocker sa-test]# kubectl apply -f sa.yaml
serviceaccount/abcdocker-sa created
clusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding created

#這裡我們可以看到sa和clusterrolebinding已經被創建

我們可以過濾到sa和clusterrolebinding

[root@abcdocker sa-test]# kubectl get sa,clusterrolebinding -n kube-system|grep abcdocker
serviceaccount/abcdocker-sa 1 7m50s

clusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding 7m50s

接下來我們驗證還是使用創建的sa中的secret token進行訪問dashboard，查看對應權限是否正常

[root@abcdocker sa-test]# kubectl describe sa -n kube-system abcdocker-sa
Name: abcdocker-sa
Namespace: kube-system
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
 {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"abcdocker-sa","namespace":"kube-system"}}
Image pull secrets: <none>
Mountable secrets: abcdocker-sa-token-qkb7c
Tokens: abcdocker-sa-token-qkb7c
Events: <none>
[root@abcdocker sa-test]# kubectl get secrets -n kube-system abcdocker-sa-token-qkb7c -o yaml
apiVersion: v1
data:
...
 token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUpoWW1Oa2IyTnJaWEl0YzJFdGRHOXJaVzR0Y1d0aU4yTWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lZV0pqWkc5amEyVnlMWE5oSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWRXbGtJam9pTW1VMVpXRmpOV1F0TVRJNE9DMHhNV1ZoTFdFMU4yVXROVEkxTkRBd1pEZGlNamcwSWl3aWMzVmlJam9pYzNsemRHVnRPbk5sY25acFkyVmhZMk52ZFc1ME9tdDFZbVV0YzNsemRHVnRPbUZpWTJSdlkydGxjaTF6WVNKOS5uQlpIc0c5Yjhfa1ExcktDVFoyVDRlVjYzWGFsNnJ5TnRuOHBIODNEYnJSTTJMZEdwWThfa1hVWWYxd1dUMHFVTk1oVUZhZ2FaNXc2cmpwM2pwVkhwZEVCYnM2akhCRTJzY0tJYXZHMFVlQUtfaWl6TDRDWU8xakMwa0pxWk5YcmhWdWVfb0xsY0NLVTNCRHZ0QWVSS2tTbWZJdGpLZU5VT1pSZWlPT05KMzJIcmNpdUdDZ2xkWXpXSXp5OFd1dElXaGRoRVRHUjRNY2FZUVB0eWR5Sjk5bU5fMGk1NVdKQmI0a1VjbFBZeERmWlFnMlg0UmFxdl84ZS1ySGtoWnBjQThFVmQwQ0JfZFMyVTRCSjNRN0VqQ2tnOFZvNUkxa1llMFlDMEJxWS1NS2dGekR1QXphblpiTTV5dU9nanBxTG9Gd0s5UHYya0t3Mld5Vjh0NWM1RWc=
...
/<none>/<none>/<none>

同樣還是將token使用base64進行解密
echo "xx" |base64 -d

image_1dqr7kqf7do84001rp317et1ipe54.png-628.5kB

接下來我們使用獲取到的token訪問dashboard，查看相關權限是否正常 (clusterRoleBinding權限最大，所以說應該所有權限都有)

image_1dqr7n4sc1etk1sak919g31e9t5h.png-74.1kB

訪問進來就沒有error報錯，也就是現在sa已經綁定到最高權限的clusterrole。可以訪問所有資源對象，並且增刪改查權限都有

image_1dqr7onu2jo8lkiun8ls19u5u.png-205.9kB

閱讀更多 DevOps運維 的文章

關鍵字: 摘選 kind example