本文主要基于Kubernetes1.21.9和Linux操作系統CentOS7.4。
(資料圖片僅供參考)
| 服務器版本 | docker軟件版本 | Kubernetes(k8s)集群版本 | CPU架構 |
|---|---|---|---|
| CentOS Linux release 7.4.1708 (Core) | Docker version 20.10.12 | v1.21.9 | x86_64 |
Kubernetes集群架構:k8scloude1作為master節點,k8scloude2,k8scloude3作為worker節點。
| 服務器 | 操作系統版本 | CPU架構 | 進程 | 功能描述 |
|---|---|---|---|---|
| k8scloude1/192.168.110.130 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker,kube-apiserver,etcd,kube-scheduler,kube-controller-manager,kubelet,kube-proxy,coredns,calico | k8s master節點 |
| k8scloude2/192.168.110.129 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker,kubelet,kube-proxy,calico | k8s worker節點 |
| k8scloude3/192.168.110.128 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker,kubelet,kube-proxy,calico | k8s worker節點 |
Kubernetes作為目前最流行的容器編排平臺之一,提供了強大的安全性能。在Kubernetes集群中,訪問控制是保障集群安全的重要組成部分。其中,權限管理是訪問控制的核心。本篇博客將介紹Kubernetes中的權限管理機制之RBAC鑒權。
使用RBAC鑒權的前提是已經有一套可以正常運行的Kubernetes集群,關于Kubernetes(k8s)集群的安裝部署,可以查看博客《Centos7 安裝部署Kubernetes(k8s)集群》https://www.cnblogs.com/renshengdezheli/p/16686769.html。
三.Kubernetes訪問控制用戶使用 kubectl、客戶端庫或構造 REST 請求來訪問 Kubernetes API。 用戶賬戶和 Kubernetes 服務賬號都可以被鑒權訪問 API。 當請求到達 API 時,它會經歷多個階段,如下圖所示:
整體過程簡述:請求發起方進行K8s API請求,建立 TLS 后,經過Authentication(認證)、Authorization(鑒權)、AdmissionControl(準入控制)三個階段的校驗,最后把請求轉化為對K8s對象的變更操作持久化至etcd中。
關于Authentication(認證)詳細內容請查看博客《Kubernetes(k8s)訪問控制:身份認證》。
四.鑒權簡介在Kubernetes中,鑒權(Authorization)是指檢查用戶是否有權限執行請求所需的操作的過程。鑒權機制由Kubernetes API server實現,并可以支持RBAC(基于角色的訪問控制)、ABAC(基于屬性的訪問控制)和Node鑒權等多種方式。
RBAC/ABAC/Node鑒權區別:
RBAC(Role-Based Access Control):基于角色的訪問控制。RBAC允許管理員定義一系列角色,每個角色包含一組權限和資源。然后,將用戶或者服務賬戶與相應的角色綁定起來。這樣,用戶或者服務賬戶就可以訪問其相應的角色包含的資源和權限了。RBAC是Kubernetes推薦的鑒權方式。ABAC(Attribute-Based Access Control):基于屬性的訪問控制。ABAC允許管理員定義一系列策略,每個策略包含多個屬性,例如用戶身份、資源類型、操作類型等。當一個請求被發送到API server時,API server會檢查該請求是否滿足所有匹配的策略。Node鑒權:在Kubernetes中,每個節點都有主機名和IP地址。Node鑒權是指Kubernetes API server根據節點信息對請求進行授權的過程。可以使用Node鑒權來限制哪些節點可以訪問某些資源。在本篇博客中,我們將重點介紹RBAC鑒權。
五.配置客戶端機器如下是我們的kubernetes集群。
[root@k8scloude1 ~]# kubectl get nodes -o wideNAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIMEk8scloude1 Ready control-plane,master 67d v1.21.0 192.168.110.130 CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://20.10.12k8scloude2 Ready 67d v1.21.0 192.168.110.129 CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://20.10.12k8scloude3 Ready 67d v1.21.0 192.168.110.128 CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://20.10.12 先準備一臺機器作為訪問k8s集群的客戶端,機器etcd1作為客戶端,不是k8s集群的一部分。
訪問k8s集群需要客戶端工具kubectl,下面安裝kubectl,--disableexcludes=kubernetes 表示禁掉除了這個之外的別的倉庫。
[root@etcd1 ~]# yum -y install kubectl-1.21.0-0 --disableexcludes=kubernetes配置kubectl命令自動補全。
[root@etcd1 ~]# vim /etc/profile[root@etcd1 ~]# grep source /etc/profilesource <(kubectl completion bash)使配置生效。
[root@etcd1 ~]# source /etc/profile[root@etcd1 ~]# kubectl get nodeThe connection to the server localhost:8080 was refused - did you specify the right host or port?六.設置k8s集群允許所有請求訪問kubernetes默認的授權模式為:authorization-mode=Node,RBAC。
[root@k8scloude1 ~]# ls /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml[root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml - --authorization-mode=Node,RBAC設置k8s允許所有請求訪問。
[root@k8scloude1 ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml [root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml #- --authorization-mode=Node,RBAC - --authorization-mode=AlwaysAllow重啟kubelet使配置生效。
[root@k8scloude1 ~]# systemctl restart kubelet[root@k8scloude1 ~]# systemctl status kubelet● kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since 五 2022-03-18 18:36:24 CST; 11s ago Docs: https://kubernetes.io/docs/ Main PID: 28054 (kubelet) Memory: 42.4M CGroup: /system.slice/kubelet.service └─28054 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network-plugin=cni --pod-in...當- --authorization-mode=AlwaysAllow 設置為允許所有請求之后,客戶端機器可以隨意訪問所有資源。
kctest這個自定義的kubeconfig文件博客《Kubernetes(k8s)訪問控制:身份認證》已經詳細講解過了,這里就不贅述了。
在etcd1機器上可以訪問任何資源。
[root@etcd1 ~]# kubectl get nodes --kubeconfig=kctest NAME STATUS ROLES AGE VERSIONk8scloude1 Ready control-plane,master 68d v1.21.0k8scloude2 Ready 68d v1.21.0k8scloude3 Ready 68d v1.21.0[root@etcd1 ~]# kubectl get pod -A --kubeconfig=kctest NAMESPACE NAME READY STATUS RESTARTS AGEingress-nginx ingress-nginx-admission-create-2lg57 0/1 Completed 0 31dingress-nginx ingress-nginx-admission-patch-hd7p4 0/1 Completed 1 31dingress-nginx ingress-nginx-controller-59b8bf5fdc-t2f7z 1/1 Running 14 31dkube-system calico-kube-controllers-6b9fbfff44-4jzkj 1/1 Running 78 68dkube-system calico-node-bdlgm 1/1 Running 38 68dkube-system calico-node-hx8bk 1/1 Running 38 68dkube-system calico-node-nsbfs 1/1 Running 38 68dkube-system coredns-545d6fc579-7wm95 1/1 Running 38 68dkube-system coredns-545d6fc579-87q8j 1/1 Running 38 68dkube-system etcd-k8scloude1 1/1 Running 38 68dkube-system kube-apiserver-k8scloude1 0/1 Running 1 8m36skube-system kube-controller-manager-k8scloude1 1/1 Running 45 68dkube-system kube-proxy-599xh 1/1 Running 38 68dkube-system kube-proxy-lpj8z 1/1 Running 38 68dkube-system kube-proxy-zxlk9 1/1 Running 38 68dkube-system kube-scheduler-k8scloude1 1/1 Running 45 68dkube-system metrics-server-bcfb98c76-n4fnb 1/1 Running 42 60dmetallb-system controller-7dcc8764f4-qdwl2 1/1 Running 24 34dmetallb-system speaker-892pm 1/1 Running 16 34dmetallb-system speaker-jfccb 1/1 Running 16 34dmetallb-system speaker-nkrgk 1/1 Running 16 34dvolume nfs-client-provisioner-76c576954d-5x7t2 1/1 Running 16 57d 七.設置k8s集群拒絕所有請求訪問設置k8s拒絕所有請求訪問。
[root@k8scloude1 ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml #設置為拒絕所有請求[root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml #- --authorization-mode=Node,RBAC - --authorization-mode=AlwaysDeny重啟kubelet使配置生效。
[root@k8scloude1 ~]# systemctl restart kubelet設置為拒絕所有請求 - --authorization-mode=AlwaysDeny之后,客戶端機器訪問不了了。
[root@etcd1 ~]# kubectl get pod -A --kubeconfig=kctest error: the server doesn"t have a resource type "pod"[root@etcd1 ~]# kubectl get nodes --kubeconfig=kctest error: the server doesn"t have a resource type "nodes"[root@etcd1 ~]# kubectl get node --kubeconfig=kctest error: the server doesn"t have a resource type "node"設置為拒絕所有請求 - --authorization-mode=AlwaysDeny之后,admin管理員用戶無影響,其他用戶訪問不了。
[root@k8scloude1 ~]# kubectl get nodeNAME STATUS ROLES AGE VERSIONk8scloude1 Ready control-plane,master 68d v1.21.0k8scloude2 Ready 68d v1.21.0k8scloude3 Ready 68d v1.21.0 八.RBAC授權RBAC支持基于角色的授權,即將一組權限分配給一個角色,再將該角色分配給一個或多個用戶或服務賬戶。在Kubernetes中,RBAC鑒權由以下三個部分組成:
Role:針對特定命名空間(Namespace)內的資源定義一組操作權限。RoleBinding:將Role和Subject(User或ServiceAccount)關聯起來,以便Subject能夠執行Role所定義的操作。ClusterRole和ClusterRoleBinding:類似于上述兩個對象,但作用于整個集群。8.1 role,rolebinding想要使用RBAC授權,需要恢復- --authorization-mode=Node,RBAC,想要查看什么,都是我們敲命令獲取,其實有很多我們看不到的操作(比如master和worker之間交互查詢,審計等等),- --authorization-mode=Node 表示允許worker向master查詢相應信息,想要--authorization-mode=Node生效,--enable-admission-plugins=NodeRestriction準入控制器要開啟。
[root@k8scloude1 ~]# vim /etc/kubernetes/manifests/kube-apiserver.yaml [root@k8scloude1 ~]# grep authorization-mode /etc/kubernetes/manifests/kube-apiserver.yaml - --authorization-mode=Node,RBAC #- --authorization-mode=AlwaysDeny重啟kubelet使配置生效。
[root@k8scloude1 ~]# systemctl restart kubelet管理員擁有所有權限,查看管理員的權限就可以知道k8s有哪些權限。
[root@k8scloude1 ~]# kubectl describe clusterrole cluster-adminName: cluster-adminLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate: truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- *.* [] [] [*] [*] [] [*]可以看到admin角色對各種資源Resources的權限Verbs。
[root@k8scloude1 ~]# kubectl describe clusterrole adminName: adminLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate: truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- rolebindings.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] roles.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] ...... services/proxy [] [] [get list watch create delete deletecollection patch update] bindings [] [] [get list watch] events [] [] [get list watch] limitranges [] [] [get list watch] namespaces/status [] [] [get list watch] namespaces [] [] [get list watch] persistentvolumeclaims/status [] [] [get list watch] pods/log [] [] [get list watch] pods/status [] [] [get list watch] replicationcontrollers/status [] [] [get list watch] ...... pods.metrics.k8s.io [] [] [get list watch] ingresses.networking.k8s.io/status [] [] [get list watch] poddisruptionbudgets.policy/status [] [] [get list watch] serviceaccounts [] [] [impersonate create delete deletecollection patch update get list watch]8.1.1 給test用戶授予對pod的get和list權限注意:RBAC不是直接把權限授予用戶,而是把權限都放在角色role里,再把角色role綁定rolebinding到用戶,這樣用戶就具有了相應的權限,注意對于命名空間ns1里的角色role1,命名空間ns2不能使用。
除了role,還有clusterrole,role是歸屬于某一個namespace,clusterrole是全局生效的,clusterrole除了可以使用rolebinding綁定之外,還可以使用clusterrolebingding綁定,rolebinding歸屬于某一個命名空間,clusterrolebingding全局生效。
查看角色role。
[root@k8scloude1 ~]# kubectl get roleNo resources found in safe namespace.[root@k8scloude1 ~]# cd safe/我們使用yaml文件的方式創建角色role :kubectl create role role1 --verb=get,list --resource=pods --dry-run=client -o yaml > role1.yaml。
--verb=get,list指定權限為get和list,--resource=pods表示權限作用在pod上。
[root@k8scloude1 safe]# kubectl create role role1 --verb=get,list --resource=pods --dry-run=client -o yaml > role1.yaml查看yaml文件,功能為:在 Kubernetes 集群中創建一個叫做 "role1" 的角色(Role),該角色具有操作(Kubernetes Pod)的權限。
[root@k8scloude1 safe]# vim role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null #name: role1: 該角色的名稱為 "role1"。 name: role1#rules: 角色的規則部分定義了角色能夠執行的操作列表。 rules:#- apiGroups: [""]: apiGroups 字段指定資源所屬的 API 組(或者不屬于任何組)。在本例中,Pod 不屬于任何 API 組,所以值為空字符串。- apiGroups: - "" #resources: ["pods"]: resources 字段指定角色能夠訪問的資源列表。在本例中,只有 Pod 是被授權的資源。 resources: - pods #verbs: ["get", "list"]: verbs 字段列出了角色可用的動詞列表。在本例中,角色可以執行 "get" 和 "list" 操作。這意味著此角色可以查看 Pod 的詳細信息和列表信息。 verbs: - get - list生成role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 created查看role。
[root@k8scloude1 safe]# kubectl get roleNAME CREATED ATrole1 2022-03-19T09:52:13Z查看role的權限:對pod具有get list權限。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list] 把角色role1綁定到test用戶上,test用戶不屬于任何命名空間。
[root@k8scloude1 safe]# kubectl create rolebinding rolebind1 --role=role1 --user=testrolebinding.rbac.authorization.k8s.io/rolebind1 created查看rolebinding。
[root@k8scloude1 safe]# kubectl get rolebindingNAME ROLE AGErolebind1 Role/role1 110s查看rolebind1的描述信息。
[root@k8scloude1 safe]# kubectl describe rolebinding rolebind1 Name: rolebind1Labels: Annotations: Role: Kind: Role Name: role1Subjects: Kind Name Namespace ---- ---- --------- User test 在客戶端進行權限測試,把角色role1綁定給test用戶之后,客戶端具有了safe命名空間里pod的查詢權限。
[root@etcd1 ~]# kubectl get pods --kubeconfig=kctest -n safeNo resources found in safe namespace.客戶端不具有default命名空間里pod的查詢權限。
[root@etcd1 ~]# kubectl get pods --kubeconfig=kctest Error from server (Forbidden): pods is forbidden: User "test" cannot list resource "pods" in API group "" in the namespace "default"8.1.2 增加對pod的創建權限如下是使用nginx鏡像創建pod的配置文件。
[root@etcd1 ~]# cat pod.yaml apiVersion: v1kind: Podmetadata: labels: test: podtest name: podtestspec: #當需要關閉容器時,立即殺死容器而不等待默認的30秒優雅停機時長。 terminationGracePeriodSeconds: 0 containers: - name: nginx image: nginx #imagePullPolicy: IfNotPresent:表示如果本地已經存在該鏡像,則不重新下載;否則從遠程 Docker Hub 下載該鏡像 imagePullPolicy: IfNotPresent現在想在客戶端創建一個pod,用戶test只對pod有get ,list權限,沒有創建pod權限,創建失敗。
[root@etcd1 ~]# kubectl apply -f pod.yaml -n safe --kubeconfig=kctest Error from server (Forbidden): error when creating "pod.yaml": pods is forbidden: User "test" cannot create resource "pods" in API group "" in the namespace "safe"修改yaml文件,添加pod的create權限。
[root@k8scloude1 safe]# vim role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:- apiGroups: - "" resources: - pods #添加了創建權限create verbs: - get - list - create應用role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 configured現在role1具有了對pod的get list create權限。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list create] role1添加pod的create權限之后,成功在客戶端創建pod。
[root@etcd1 ~]# kubectl apply -f pod.yaml -n safe --kubeconfig=kctest pod/podtest created[root@etcd1 ~]# kubectl get pod -n safe --kubeconfig=kctest NAME READY STATUS RESTARTS AGEpodtest 1/1 Running 0 22s8.1.3 增加對pod的刪除權限用戶test沒有pod刪除權限。
[root@etcd1 ~]# kubectl delete pod podtest -n safe --kubeconfig=kctest Error from server (Forbidden): pods "podtest" is forbidden: User "test" cannot delete resource "pods" in API group "" in the namespace "safe"給角色role1增加刪除pod的權限。
[root@k8scloude1 safe]# vim role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:- apiGroups: - "" resources: - pods #增加刪除權限delete verbs: - get - list - create - delete應用role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 configured現在role1具有了對pod的get list create delete權限。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list create delete] 給角色role1增加刪除pod的權限之后,客戶端成功刪除了pod。
[root@etcd1 ~]# kubectl delete pod podtest -n safe --kubeconfig=kctest pod "podtest" deleted[root@etcd1 ~]# kubectl get pod -n safe --kubeconfig=kctest No resources found in safe namespace.8.1.4 增加對svc的get list create delete權限test用戶沒有對services的list權限。
[root@etcd1 ~]# kubectl get svc -n safe --kubeconfig=kctest Error from server (Forbidden): services is forbidden: User "test" cannot list resource "services" in API group "" in the namespace "safe"修改yaml文件,對role1添加service的get list create delete權限,注意:services不能簡寫。
[root@k8scloude1 safe]# vim role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:- apiGroups: - "" #資源里增加services resources: - pods - services verbs: - get - list - create - delete應用role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 configured查看角色的描述信息,角色role1增加了services的get list create delete權限。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list create delete] services [] [] [get list create delete] 給角色role1增加了services的get list create delete權限之后,客戶端可以查詢svc了。
[root@etcd1 ~]# kubectl get svc -n safe --kubeconfig=kctest No resources found in safe namespace.8.1.5 增加對deployments的get list create delete權限客戶端沒有對deployments的list權限。
[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "safe"修改yaml文件,給role1添加deployments的get list create delete權限。
[root@k8scloude1 safe]# vim role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:- apiGroups: - "" resources: - pods - services - deployments verbs: - get - list - create - delete應用role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 configured查看角色的描述信息,角色role1增加了deployments的get list create delete權限。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- deployments [] [] [get list create delete] pods [] [] [get list create delete] services [] [] [get list create delete] 給角色role1增加了deployments的get list create delete權限之后,客戶端還是沒有對deployments的list權限。
[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "safe"給角色role1增加了deployments的get list create delete權限之后,客戶端還是沒有對deployments的list權限,原因為:pod,service對應的apiVersion為v1,deploy對應的apiVersion為apps/v1。
apiVersion的結構有 xx ,yy/zz ,對于xx結構,apiGroups寫為:apiGroups:"",對于yy/zz結構,apiGroups寫為:apiGroups:"yy"。
如果apiGroups只寫為“”,不寫"apps"則pods,services生效,deployments不生效,因為沒有父級,如果apiGroups只寫為"apps",不寫""則pods,services不生效,deployments生效,因為pods,services沒有父級。
下面才是正確的寫法,修改yaml文件。
[root@k8scloude1 safe]# vi role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:#- apiGroups: ["apps"]: apiGroups 字段指定資源所屬的 API 組(或者不屬于任何組)。在本例中,deployments 屬于 apps/v1 組,所以值為apps。- apiGroups: - "" - "apps" resources: - pods - services - deployments verbs: - get - list - create - delete應用role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 configured查看role1的描述信息。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- deployments [] [] [get list create delete] pods [] [] [get list create delete] services [] [] [get list create delete] deployments.apps [] [] [get list create delete] pods.apps [] [] [get list create delete] services.apps [] [] [get list create delete] 給role1添加deployment的get list create delete權限之后,客戶端可以查詢deploy了。
[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest No resources found in safe namespace.如下是使用Nginx鏡像創建deploy的yaml文件。
[root@etcd1 ~]# cat nginx.yaml apiVersion: apps/v1kind: Deploymentmetadata: creationTimestamp: null labels: app: nginx name: nginxspec: #5個副本 replicas: 5 selector: matchLabels: app: nginx strategy: {} template: metadata: creationTimestamp: null labels: app: nginx spec: #當需要關閉容器時,立即殺死容器而不等待默認的30秒優雅停機時長。 terminationGracePeriodSeconds: 0 containers: - image: nginx name: nginx #imagePullPolicy: IfNotPresent:表示如果本地已經存在該鏡像,則不重新下載;否則從遠程 Docker Hub 下載該鏡像 imagePullPolicy: IfNotPresent resources: {}status: {}在客戶端創建deploy,由于被授權了,deploy創建成功。
[root@etcd1 ~]# kubectl apply -f nginx.yaml -n safe --kubeconfig=kctest deployment.apps/nginx created[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest NAME READY UP-TO-DATE AVAILABLE AGEnginx 5/5 5 5 23s[root@etcd1 ~]# kubectl get pod -n safe --kubeconfig=kctest NAME READY STATUS RESTARTS AGEnginx-6cf858f6cf-62m8t 1/1 Running 0 72snginx-6cf858f6cf-74nzb 1/1 Running 0 72snginx-6cf858f6cf-bw84g 1/1 Running 0 72snginx-6cf858f6cf-cmj95 1/1 Running 0 72snginx-6cf858f6cf-fzs4l 1/1 Running 0 72s剛才給role1添加deployments權限寫的不好,如下為優化后的寫法:
[root@k8scloude1 safe]# vim role1.yaml #對于給role1添加權限還可以有另一種寫法(這種方法更好),如下[root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:- apiGroups: - "" resources: - pods - services verbs: - get - list - create - delete- apiGroups: - "apps" resources: - deployments verbs: - get - list - create - delete8.1.6 增加對deployments的patch權限把nginx的deploy的副本數變為2,發現用戶test沒有deployments/scale的patch權限。
[root@etcd1 ~]# kubectl scale deploy nginx --replicas=2 -n safe --kubeconfig=kctest Error from server (Forbidden): deployments.apps "nginx" is forbidden: User "test" cannot patch resource "deployments/scale" in API group "apps" in the namespace "safe"修改yaml文件,添加deployments/scale的patch權限。
[root@k8scloude1 safe]# vim role1.yaml [root@k8scloude1 safe]# cat role1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: role1rules:- apiGroups: - "" resources: - pods - services - deployments verbs: - get - list - create - delete- apiGroups: - "apps" resources: - deployments - deployments/scale verbs: - get - list - create - delete - patch應用role。
[root@k8scloude1 safe]# kubectl apply -f role1.yaml role.rbac.authorization.k8s.io/role1 configured查看role1的描述信息。
[root@k8scloude1 safe]# kubectl describe role role1 Name: role1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- deployments.apps/scale [] [] [get list create delete patch] deployments.apps [] [] [get list create delete patch] deployments [] [] [get list create delete] pods [] [] [get list create delete] services [] [] [get list create delete] 添加deployments/scale的patch權限之后,客戶端可以修改副本數了。
[root@etcd1 ~]# kubectl scale deploy nginx --replicas=2 -n safe --kubeconfig=kctest deployment.apps/nginx scaled[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest NAME READY UP-TO-DATE AVAILABLE AGEnginx 2/2 2 2 7m19s刪除deploy。
[root@etcd1 ~]# kubectl delete -f nginx.yaml -n safe --kubeconfig=kctest deployment.apps "nginx" deleted[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest No resources found in safe namespace.8.2 clusterrole,clusterrolebinding上面做的權限都是role,rolebinding,下面開始clusterrole,clusterrolebinding。
刪除role。
[root@k8scloude1 safe]# kubectl get roleNAME CREATED ATrole1 2022-03-19T09:52:13Z[root@k8scloude1 safe]# kubectl delete -f role1.yaml role.rbac.authorization.k8s.io "role1" deleted[root@k8scloude1 safe]# kubectl get roleNo resources found in safe namespace.刪除rolebinding。
[root@k8scloude1 safe]# kubectl get rolebindingNAME ROLE AGErolebind1 Role/role1 25h[root@k8scloude1 safe]# kubectl delete rolebinding rolebind1 rolebinding.rbac.authorization.k8s.io "rolebind1" deleted[root@k8scloude1 safe]# kubectl get rolebindingNo resources found in safe namespace.8.2.1 test用戶授予對Pod、Service 、Deployment 的get 和 create 權限生成創建clusterrole的yaml文件,--verb指定權限,--resource指定作用的資源。
[root@k8scloude1 safe]# kubectl create clusterrole clusterrole1 --verb=get,create --resource=pod,svc,deploy --dry-run=client -o yaml >clusterrole1.yaml查看ClusterRole的yaml文件,功能為:在 Kubernetes 集群中創建一個叫做 "clusterrole1" 的集群角色(ClusterRole),該角色具有對 Pod、Service 和 Deployment 資源的操作權限。
使用這個 YAML 文件在 Kubernetes 中創建 "clusterrole1" 集群角色后,該角色將能夠訪問 Pod、Service 和 Deployment 資源,并且具有 get 和 create 操作權限。
[root@k8scloude1 safe]# vim clusterrole1.yaml [root@k8scloude1 safe]# cat clusterrole1.yaml apiVersion: rbac.authorization.k8s.io/v1#kind: ClusterRole: ClusterRole 是 Kubernetes 集群級別的角色授權機制,與 Role 類似,但是它可以跨命名空間使用。kind: ClusterRolemetadata: creationTimestamp: null name: clusterrole1rules:- apiGroups: - "" resources: - pods - services verbs: - get - create- apiGroups: - apps resources: - deployments verbs: - get - create應用clusterrole。
[root@k8scloude1 safe]# kubectl apply -f clusterrole1.yaml clusterrole.rbac.authorization.k8s.io/clusterrole1 created查看clusterrole。
[root@k8scloude1 safe]# kubectl get clusterrole | grep clusterrole1clusterrole1 2022-03-20T11:24:36Zkubernetes集群自帶的clusterrole有很多。
[root@k8scloude1 safe]# kubectl get clusterrole | wc -l75把集群角色clusterrole1使用clusterrolebinding綁定給用戶test。
[root@k8scloude1 safe]# kubectl create clusterrolebinding clusterrolebinding1 --clusterrole=clusterrole1 --user=testclusterrolebinding.rbac.authorization.k8s.io/clusterrolebinding1 created查看clusterrolebinding。
[root@k8scloude1 safe]# kubectl get clusterrolebinding | grep clusterrolebinding1clusterrolebinding1 ClusterRole/clusterrole1 25s[root@k8scloude1 safe]# kubectl get clusterrolebinding | wc -l60查看集群綁定的描述信息。
[root@k8scloude1 safe]# kubectl describe clusterrolebinding clusterrolebinding1Name: clusterrolebinding1Labels: Annotations: Role: Kind: ClusterRole Name: clusterrole1Subjects: Kind Name Namespace ---- ---- --------- User test 查看集群角色的描述信息。
[root@k8scloude1 safe]# kubectl describe clusterrole clusterrole1 Name: clusterrole1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get create] services [] [] [get create] deployments.apps [] [] [get create] 8.2.2 增加list權限在客戶端進行測試,設置了clusterrole,clusterrolebinding之后,發現用戶test沒有對deploy的list權限。
[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest Error from server (Forbidden): deployments.apps is forbidden: User "test" cannot list resource "deployments" in API group "apps" in the namespace "safe"修改yaml文件,增加list權限。
[root@k8scloude1 safe]# vim clusterrole1.yaml #添加list權限[root@k8scloude1 safe]# cat clusterrole1.yaml apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: creationTimestamp: null name: clusterrole1rules:- apiGroups: - "" resources: - pods - services verbs: - get - create - list- apiGroups: - apps resources: - deployments verbs: - get - create - list應用clusterrole。
[root@k8scloude1 safe]# kubectl apply -f clusterrole1.yaml clusterrole.rbac.authorization.k8s.io/clusterrole1 configured查看clusterrole1的描述信息。
[root@k8scloude1 safe]# kubectl describe clusterrole clusterrole1 Name: clusterrole1Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get create list] services [] [] [get create list] deployments.apps [] [] [get create list] clusterrole1添加了list權限之后,客戶端可以get信息了。
[root@etcd1 ~]# kubectl get deploy -n safe --kubeconfig=kctest No resources found in safe namespace.[root@etcd1 ~]# kubectl get deploy -n default --kubeconfig=kctest No resources found in default namespace.可以發現,clusterrolebinding全局生效,在所有namespace里都生效。
[root@etcd1 ~]# kubectl get deploy -n kube-system --kubeconfig=kctest NAME READY UP-TO-DATE AVAILABLE AGEcalico-kube-controllers 1/1 1 1 70dcoredns 2/2 2 2 70dmetrics-server 1/1 1 1 69d九.總結在本篇博客中,我們介紹了Kubernetes中的權限管理機制之RBAC鑒權。通過創建Role、RoleBinding、ClusterRole和ClusterRoleBinding等對象,管理員可以有效地控制用戶和服務賬戶的訪問權限,保障集群的安全性。
除了RBAC、ABAC和Node鑒權外,Kubernetes還支持Webhook鑒權、Service Account Token Volume Projection等多種鑒權方式。同時,在進行權限管理時,管理員還需注意以下事項:
避免為用戶授予過多的權限。確保所有操作都可以被審計和跟蹤。定期審核訪問權限,確保其符合組織政策和最佳實踐。標簽: