當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

错误:在keystone中无法找到默认角色user_Kubernetes RBAC角色权限控制

發布時間：2025/3/15 编程问答 23 豆豆

生活随笔收集整理的這篇文章主要介紹了错误:在keystone中无法找到默认角色user_Kubernetes RBAC角色权限控制小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

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

在Kubernetes中所有的API對象都保存在ETCD里，可是，對這些API對象的操作，卻一定是通過訪問kube-apiserver實現的。我們需要APIServer來幫助我們授權工作，而在Kubernetes項目中，負責完成授權(Authorization)的工作機制就是RBAC: 基于角色的訪問控制 (Role-Based Access Control)

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對象
Kubernetes有一個很基本的特性就是它的所有資源都是模型化的API對象，允許執行CRUD(Create、Read、Update、Delete)操作。資源如下

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: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: mynamespace name: example-rolerules:- 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: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: User name: example-user apiGroup: rbac.authorization.k8s.ioroleRef: 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: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-clusterrolerules:- apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]###############################################kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-clusterrolebindingsubjects:- kind: User name: example-user apiGroup: rbac.authorization.k8s.ioroleRef: 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中已經內置了很多個位系統保留的ClusterRole，它們的名字都是以system:開頭。一般來說，這些內置的ClusterRole，是綁定給Kubernetes系統組件對應的ServiceAccount使用

#我們可以通過下面的命令獲取到[root@abcdocker sa-test]# kubectl get clusterrolesNAME AGEadmin 93dapprove-node-server-renewal-csr 93dcluster-admin 93dedit 93d...system:public-info-viewer 93dsystem:volume-scheduler 93dtraefik-ingress-controller 45dview 93d

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

cluster-admin
admin
edit
view

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

#我們可以通過下面的命令查看clusterrole的權限[root@abcdocker sa-test]# kubectl describe clusterrole cluster-admin -n kube-systemName: cluster-adminLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate: truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- *.* [] [] [*] [*] [] [*]

ServiceAccount

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

apiVersion: v1kind: ServiceAccountmetadata: namespace: mynamespace name: example-sa

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

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: ServiceAccount name: example-sa namespace: mynamespaceroleRef: 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.yamlapiVersion: v1kind: Podmetadata: namespace: mynamespace name: sa-token-testspec: containers: - name: nginx image: nginx:1.7.9 serviceAccountName: example-sa[root@abcdocker serveraccount]# cat role-binding.yamlkind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: ServiceAccount name: example-sa namespace: mynamespaceroleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io[root@abcdocker serveraccount]# cat role.yamlkind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: mynamespace name: example-rolerules:- apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"][root@abcdocker serveraccount]# cat role-binding.yamlkind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: example-rolebinding namespace: mynamespacesubjects:- kind: ServiceAccount name: example-sa namespace: mynamespaceroleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io#接下來我們創建命名空間[root@abcdocker serveraccount]# kubectl create namespace mynamespacenamespace/mynamespace created[root@abcdocker serveraccount]# kubectl apply -f .rolebinding.rbac.authorization.k8s.io/example-rolebinding createdrole.rbac.authorization.k8s.io/example-role createdserviceaccount/example-sa created[root@abcdocker serveraccount]# kubectl get sa -n mynamespaceNAME SECRETS AGEdefault 1 26sexample-sa 1 22s[root@abcdocker serveraccount]# kubectl get sa -n mynamespace example-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata: 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-525400d7b284secrets:- name: example-sa-token-wms94

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

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

apiVersion: v1kind: Podmetadata: namespace: mynamespace name: sa-token-testspec: containers: - name: nginx image: nginx serviceAccountName: example-sa #在最下面一行我們定義了一個名為example-sa

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

[root@abcdocker serveraccount]# kubectl describe pod -n mynamespace sa-token-testName: sa-token-testNamespace: 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/bashroot@sa-token-test:/# ls /var/run/secrets/kubernetes.io/serviceaccountca.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:

而對應的用戶組則是

system:serviceaccounts:

比如，我們可以在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-systemserviceaccount/test-sa created

接下來可以查看一下sa

[root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata: 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-525400d7b284secrets:- name: test-sa-token-fs4fx

可以通過get secret查看

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

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

#yaml文件如下cat >>sa-role.yaml<

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

cat >>sa-rolebinding.yaml<

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

#首先我們復制我們創建sa中secret里面的token

[root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yamlapiVersion: v1kind: ServiceAccountmetadata: 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 yamlapiVersion: v1data:... 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<

我們可以過濾到sa和clusterrolebinding

[root@abcdocker sa-test]# kubectl get sa,clusterrolebinding -n kube-system|grep abcdockerserviceaccount/abcdocker-sa 1 7m50sclusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding 7m50s

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

[root@abcdocker sa-test]# kubectl describe sa -n kube-system abcdocker-saName: abcdocker-saNamespace: kube-systemLabels: Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"abcdocker-sa","namespace":"kube-system"}}Image pull secrets: Mountable secrets: abcdocker-sa-token-qkb7cTokens: abcdocker-sa-token-qkb7cEvents: [root@abcdocker sa-test]# kubectl get secrets -n kube-system abcdocker-sa-token-qkb7c -o yamlapiVersion: v1data:... token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUpoWW1Oa2IyTnJaWEl0YzJFdGRHOXJaVzR0Y1d0aU4yTWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lZV0pqWkc5amEyVnlMWE5oSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWRXbGtJam9pTW1VMVpXRmpOV1F0TVRJNE9DMHhNV1ZoTFdFMU4yVXROVEkxTkRBd1pEZGlNamcwSWl3aWMzVmlJam9pYzNsemRHVnRPbk5sY25acFkyVmhZMk52ZFc1ME9tdDFZbVV0YzNsemRHVnRPbUZpWTJSdlkydGxjaTF6WVNKOS5uQlpIc0c5Yjhfa1ExcktDVFoyVDRlVjYzWGFsNnJ5TnRuOHBIODNEYnJSTTJMZEdwWThfa1hVWWYxd1dUMHFVTk1oVUZhZ2FaNXc2cmpwM2pwVkhwZEVCYnM2akhCRTJzY0tJYXZHMFVlQUtfaWl6TDRDWU8xakMwa0pxWk5YcmhWdWVfb0xsY0NLVTNCRHZ0QWVSS2tTbWZJdGpLZU5VT1pSZWlPT05KMzJIcmNpdUdDZ2xkWXpXSXp5OFd1dElXaGRoRVRHUjRNY2FZUVB0eWR5Sjk5bU5fMGk1NVdKQmI0a1VjbFBZeERmWlFnMlg0UmFxdl84ZS1ySGtoWnBjQThFVmQwQ0JfZFMyVTRCSjNRN0VqQ2tnOFZvNUkxa1llMFlDMEJxWS1NS2dGekR1QXphblpiTTV5dU9nanBxTG9Gd0s5UHYya0t3Mld5Vjh0NWM1RWc=...

同樣還是將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

總結

以上是生活随笔為你收集整理的错误:在keystone中无法找到默认角色user_Kubernetes RBAC角色权限控制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： java中的STL库_C++11 STL
下一篇： python flask源码解析_Fla