Kubernetes_授权认证_RBAC_静态Pod网关apiserver底层的RBAC授权
系列文章目錄
文章目錄
- 系列文章目錄
- 前言
- 一、RBAC整體架構圖
- 二、RBAC授權規則
- 三、Kubernetes RBAC實踐
- 3.1 實踐:User --> Rolebinding --> Role
- 3.2 實踐:User --> ClusterRolebinding --> ClusterRole
- 3.3 實踐:User --> Rolebinding --> Clusterrole
- 總結
前言
RBAC(Role-Based Access Control,基于角色的訪問控制)是一種新型、靈活且使用廣泛的訪問控制機制,它將權限授予“角色”(role)之上,這一點有別于傳統訪問機制中將權限直接賦予使用者的方式。
在RBAC中,用戶(User)就是一個可以獨立訪問計算機系統中的數據或者用數據表示的其他資源的主體(Subject)。角色是指一個組織或任務中的工作或者位置,它代表一種權利、資格和責任。許可(Permission)就是允許對一個或多個客體(Object)執行的操作。一個用戶可以經授權而擁有多個角色,一個角色可由多個用戶構成;每個角色可擁有多種許可,每個許可也可授權給多個不同的角色。每個操作可施加于多個客體(受控對象),每個客體也可以接受多個操作。
小結:RBAC簡單來說就是讓一個用戶(Users)扮演一個角色(Role),角色擁有權限,讓用戶綁定該角色;隨后在授權機制中,只需要將權限授權給某個角色,此時用戶將獲取對應角色的權限,從而實現角色的訪問控制。
一、RBAC整體架構圖
RBAC(Role Based Access Control):基于角色訪問控制授權。
允許管理員通過Kubernetes API動態配置授權策略。RBAC就是用戶通過角色與權限進行關聯。
RBAC只有授權,沒有拒絕授權,所以只需要定義允許該用戶做什么即可。
RBAC包括四種類型:Role、ClusterRole、RoleBinding、ClusterRoleBinding。
RBAC的三個基本概念:
Subject:被作用者,它表示k8s中的三類主體, user, group, serviceAccount
Role:角色,它其實是一組規則,定義了一組對 Kubernetes API 對象的操作權限。
RoleBinding:定義了“被作用者”和“角色”的綁定關系。
Role 和 ClusterRole
Role是一系列的權限的集合,Role只能授予單個namespace 中資源的訪問權限。
ClusterRole 跟 Role 類似,但是可以在集群中全局使用。
[root@m ~]# kubectl get rolebinding -o wide -A
NAMESPACE NAME ROLE AGE USERS GROUPS SERVICEACCOUNTS
命名空間 binding綁定名稱 角色 binding已存活時間 用戶(三種user之一) 用戶組(三種user之一) 服務賬號(三種user之一)
[root@m ~]# kubectl get clusterrolebinding -o wide -A
NAME ROLE AGE USERS GROUPS SERVICEACCOUNTS
binding綁定名稱 角色 binding已存活時間 用戶(三種user之一) 用戶組(三種user之一) 服務賬號(三種user之一)
因為user有三種,所以使用 get binding 命令,后面三列都是表示user的 USERS GROUPS SERVICEACCOUNTS
rbac 一頭是role,用來提供權限;一頭是user,包括三種,其中 user/userGroup 用來構成了 userAccount 用戶賬號體系,serviceAccount 用來構成了 serviceAccount 賬號體系,所以,學rbac就離不開 userAccount 和 serviceAccount。
另外注意,在這個過程中,屬于 kind 類資源的 role clusterRole rolebinding clusterRoleBinding serviceAccount
user和userGroup并不屬于 kind 類資源
二、RBAC授權規則
RBAC授權規則是通過四種資源來進行配置的,他們可以分為兩個組:
(1) Role(角色)和ClusterRole(集群角色),它們指定了在資源上可以執行哪些動作。
(2) RoleBinding(角色綁定)和ClusterRoleBinding(集群角色綁定),它們將上述角色綁定到特定的用戶、組或ServiceAccounts上。
角色定義了可以做什么操作,而綁定定義了誰可以做這些操作,如下圖所示:
綁定關系:
角色和集群角色,或者角色綁定和集群角色綁定之間的區別在于角色和角色綁定是名稱空間級別,而集群角色和集群角色綁定是集群級別的資源。
(1) RoleBind–Role:在kubernetes授權機制中,采用RBAC的方式進行授權,把對象的操作權限定義到一個角色當中,而將用戶綁定到該角色,從而使得用戶得到對應角色的權限。比如下圖,當用戶(User1)綁定到Role角色當中,User1就獲取了對應的NamespaceA的操作權限,但是對于NamespaceB是沒有權限進行操作的。如get,list等操作。
(2) ClusterRoleBind–ClusterRole:集群級別的授權,定義一個集群角色(ClusterRole),對集群內的所有資源都有可操作的權限,如下圖(只看藍色的線連接),當用戶(User1)通過ClusterRolebinding到ClusterRole,從而User1遍擁有了集群的操作權限。
(3) RoleBind-ClusterRole:這種方式進行綁定時,用戶僅能獲取當前名稱空間的所有權限。為什么這么繞呢?? 舉例有10個名稱空間,每個名稱空間都需要一個管理員,而每個管理員的權限是一致的。那么此時需要去定義這樣的管理員,使用RoleBinding就需要創建10個Role,這樣顯得更加繁重。為了當使用RoleBinding去綁定一個ClusterRole時,該User僅僅擁有對當前名稱空間的集群操作權限,也就是此時只需要創建一個ClusterRole就解決了以上的需求。比如下圖中的User2和User3用戶雖然綁定了ClusterRole,但是他們也只有自己的名稱空間NamespaceB中權限。
三、Kubernetes RBAC實踐
這里由于要切換用戶,使用root用戶同時不停的在kubernetes-admin用戶和上面創建的kube-user1用戶之間進行測試。故這里創建一個測試用戶打開另外一個終端進行測試。
[root@k8s-master ~]# useradd ik8s [root@k8s-master ~]# cp -rp .kube/ /home/ik8s/ [root@k8s-master ~]# chown -R ik8s.ik8s /home/ik8s/ [root@k8s-master ~]# su - ik8s [ik8s@k8s-master ~]$ kubectl config use-context kube-user1@kubernetes Switched to context "kube-user1@kubernetes". [ik8s@k8s-master ~]$ kubectl config view ...... current-context: kube-user1@kubernetes #這里可以看到當前已經切換到kube-user1用戶了 ...... [ik8s@k8s-master ~]$ kubectl get pods #測試kube-user1用戶的權限,可以看出目前它沒有任何權限 Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"3.1 實踐:User --> Rolebinding --> Role
1)角色(Role)創建。(說明:一個Role對象只能用于授予對某一單一名稱空間中資源的訪問權限)
[root@k8s-master ~]# kubectl create role -h #查看role創建幫助 ...... Usage:kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run] [options] --verb #指定權限 --resource #指定資源或者資源組 --dry-run #干跑模式并不會創建[root@k8s-master ~]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑模式查看role的定義格式 apiVersion: rbac.authorization.k8s.io/v1 kind: Role #資源類型 metadata:creationTimestamp: nullname: pods-reader #資源名稱 rules: - apiGroups: #定義對哪些api組內的資源可以進行操作- ""resources: #定義對哪些資源可以進行操作- podsverbs: #定義操作的權限- get- list- watch[root@k8s-master ~]# cd manfests/ [root@k8s-master manfests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > role-demo.yaml[root@k8s-master manfests]# vim role-demo.yaml #編寫資源清單文件 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:name: pods-readernamespace: default rules: - apiGroups:- ""resources:- podsverbs:- get- list- watch [root@k8s-master manfests]# kubectl apply -f role-demo.yaml role.rbac.authorization.k8s.io/pods-reader created [root@k8s-master manfests]# kubectl get role NAME AGE pods-reader 4s [root@k8s-master manfests]# kubectl describe role/pods-reader Name: pods-reader Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pods-reader","namespace":"default"},"rules... PolicyRule:Resources Non-Resource URLs Resource Names Verbs--------- ----------------- -------------- -----pods [] [] [get list watch] #這里表示當前定義了pods-reader這個角色對pods資源擁有get、list、watch的權限。2)角色的綁定。(RoleBinding可以引用在同一名稱空間定義的Role對象)
[root@k8s-master manfests]# kubectl create rolebinding -h #查看rolebinding創建幫助 ...... Usage:kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options] --role #指定role的名字 --user #指定哪個用戶[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --role=pods-reader --user=kube-user1 --dry-run -o yaml #干跑模式查看rolebinding的定義格式 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding #資源類型 metadata:creationTimestamp: nullname: kube-user1-read-pods #資源名稱 roleRef: #指定roleapiGroup: rbac.authorization.k8s.iokind: Rolename: pods-reader subjects: #指定user - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --role=pods-reader --user=kube-user1 --dry-run -o yaml > rolebinding-demo.yaml [root@k8s-master manfests]# vim rolebinding-demo.yaml #編輯資源清單文件 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:name: kube-user1-read-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: pods-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl apply -f rolebinding-demo.yaml rolebinding.rbac.authorization.k8s.io/kube-user1-read-pods created [root@k8s-master manfests]# kubectl get rolebinding NAME AGE kube-user1-read-pods 9s [root@k8s-master manfests]# kubectl describe rolebinding kube-user1-read-pods #查看角色綁定的信息,這里可以看到user kube-user1綁定到了pods-reader這個角色上。 Name: kube-user1-read-pods Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-pods","namespace":"... Role:Kind: RoleName: pods-reader Subjects:Kind Name Namespace---- ---- ---------User kube-user13)權限測試
這時候我們使用kube-user1用戶進行測試
[ik8s@k8s-master ~]$ kubectl config use-context kube-user1@kubernetes #如果沒有切換到該kube-user1用戶,通過kubectl config use-context進行切換[ik8s@k8s-master ~]$ kubectl get pods #在default名稱空間獲取pods信息 NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 3d nginx-statefulset-1 1/1 Running 0 3d nginx-statefulset-2 1/1 Running 0 3d nginx-statefulset-3 1/1 Running 0 3d pod-sa-demo 1/1 Running 0 27h[ik8s@k8s-master ~]$ kubectl get pods -n kube-system #測試獲取kube-system名稱空間中的pods Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "kube-system"從上面的操作可以看出,role的定義和綁定,僅作用于當前名稱空間,在獲取別的名稱空間比如kube-system名稱空間時,一樣會出現Forbidden。
3.2 實踐:User --> ClusterRolebinding --> ClusterRole
1)ClusterRole定義
ClusterRole資源對象可以授予與Role資源對象相同的權限,但由于它們屬于集群范圍的對象,也可以使用它們授予對以下幾種資源的訪問權限:
a. 集群范圍資源(例如節點,即Node)
b. 非資源類型endpoint(例如/api、/healthz等。)
c. 跨所有名稱空間的名稱空間資源(例如pod,運行kubectl get pods --all-namespaces來查詢集群中所有的pod)
2)ClusterRoleBinding定義
#這里還是使用kube-user1用戶,所以先將上面的角色綁定信息刪除 [root@k8s-master manfests]# kubectl get rolebinding #查看角色綁定信息 NAME AGE kube-user1-read-pods 27m [root@k8s-master manfests]# kubectl delete rolebinding kube-user1-read-pods #刪除前面的綁定 rolebinding.rbac.authorization.k8s.io "kube-user1-read-pods" delete [ik8s@k8s-master ~]$ kubectl get pods #刪除后再用kube-user1用戶獲取pods資源信息,就立馬出現Forbidden了 Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"[root@k8s-master manfests]# kubectl create clusterrolebinding -h Usage:kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options] --clusterrole #指定clusterrole --user #指定用戶[root@k8s-master manfests]# kubectl create clusterrolebinding kube-user1-read-all-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata:creationTimestamp: nullname: kube-user1-read-all-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl create clusterrolebinding kube-user1-read-all-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml > clusterrolebinding-demo.yaml [root@k8s-master manfests]# vim clusterrolebinding-demo.yaml #編輯資源清單文件 cat clusterrolebinding-demo.yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata:name: kube-user1-read-all-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl apply -f clusterrolebinding-demo.yaml #創建clusterrolebinding clusterrolebinding.rbac.authorization.k8s.io/kube-user1-read-all-pods created [root@k8s-master manfests]# kubectl get clusterrolebinding/kube-user1-read-all-pods NAME AGE kube-user1-read-all-pods 25s [root@k8s-master manfests]# kubectl describe clusterrolebinding/kube-user1-read-all-pods #查看clusterrolebinding資源kube-user1-read-all-pods詳細信息,可以看到kube-user1用戶已經綁定到clusterrole資源cluster-reader上了。 Name: kube-user1-read-all-pods Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-all-pod... Role:Kind: ClusterRoleName: cluster-reader Subjects:Kind Name Namespace---- ---- ---------User kube-user13)權限測試
[ik8s@k8s-master ~]$ kubectl get pods #角色綁定后再次獲取pods信息,已經可以正常查看 NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 3d1h nginx-statefulset-1 1/1 Running 0 3d1h nginx-statefulset-2 1/1 Running 0 3d1h nginx-statefulset-3 1/1 Running 0 3d1h pod-sa-demo 1/1 Running 0 28h[ik8s@k8s-master ~]$ kubectl get pods -n kube-system #切換名稱空間也是可以查看的 NAME READY STATUS RESTARTS AGE coredns-bccdc95cf-9gsn8 1/1 Running 0 8d coredns-bccdc95cf-x7m8g 1/1 Running 0 8d etcd-k8s-master 1/1 Running 0 8d kube-apiserver-k8s-master 1/1 Running 0 8d kube-controller-manager-k8s-master 1/1 Running 0 8d kube-flannel-ds-amd64-gg55s 1/1 Running 0 8d kube-flannel-ds-amd64-ssr7j 1/1 Running 5 8d kube-flannel-ds-amd64-w6f9h 1/1 Running 4 8d kube-proxy-77pbc 1/1 Running 3 8d kube-proxy-qs655 1/1 Running 3 8d kube-proxy-xffq4 1/1 Running 0 8d kube-scheduler-k8s-master 1/1 Running 0 8d[ik8s@k8s-master ~]$ kubectl delete pods/pod-sa-demo #在進行刪除pod測試時,還是會報Forbidden,這是因為在授權時就沒授予delete權限的。 Error from server (Forbidden): pods "pod-sa-demo" is forbidden: User "kube-user1" cannot delete resource "pods" in API group "" in the namespace "default"從上面的操作可以看出,clusterrole的定義和clusterrolebinding的綁定,可以獲取到集群內所有資源的對應權限。
3.3 實踐:User --> Rolebinding --> Clusterrole
將用戶kube-user1通過角色綁定(RoleBinding)到集群角色cluster-reader當中,此時kube-user1僅作用于當前名稱空間的所有pods資源的權限。
1)綁定
#首先刪除上面的clusterrolebinding [root@k8s-master manfests]# kubectl delete clusterrolebinding kube-user1-read-all-pods clusterrolebinding.rbac.authorization.k8s.io "kube-user1-read-all-pods" deleted[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:creationTimestamp: nullname: kube-user1-read-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml > rolebinding-clusterrole-demo.yaml [root@k8s-master manfests]# vim rolebinding-clusterrole-demo.yaml #編輯資源清單文件 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:name: kube-user1-read-pods roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.iokind: Username: kube-user1[root@k8s-master manfests]# kubectl apply -f rolebinding-clusterrole-demo.yaml rolebinding.rbac.authorization.k8s.io/kube-user1-read-pods created [root@k8s-master manfests]# kubectl get rolebinding kube-user1-read-pods NAME AGE kube-user1-read-pods 32s [root@k8s-master manfests]# kubectl describe rolebinding kube-user1-read-pods Name: kube-user1-read-pods Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-pods","namespace":"... Role:Kind: ClusterRoleName: cluster-reader Subjects:Kind Name Namespace---- ---- ---------User kube-user12)權限測試
[ik8s@k8s-master ~]$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 3d1h nginx-statefulset-1 1/1 Running 0 3d1h nginx-statefulset-2 1/1 Running 0 3d1h nginx-statefulset-3 1/1 Running 0 3d1h pod-sa-demo 1/1 Running 0 28h[ik8s@k8s-master ~]$ kubectl get pods -n kube-system Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "kube-system"從上面的操作可以看出,角色綁定(Rolebinding)和集群角色(ClusterRole)綁定后,用戶只擁有自己當前名稱空間的對應的權限。
總結
本文介紹了 默認的ServiceAccount 和 自定義ServiceAccount ,默認的kubeconfig文件和自建證書,rbac 基于角色的訪問控制。
工作中,操作k8s的過程中,并不需要程序員去寫 role - binding -user 這樣的rbac,也不需要修改kubeconfig 文件(user - context - cluster),也不需要自定義serviceAccount。所以,本文的實踐價值在于工作中從網上download下來的yaml文件,如果出現 rbac 的錯誤,自己知道怎樣修改,保證容器化正常部署即可。
天天打碼,天天進步!!
總結
以上是生活随笔為你收集整理的Kubernetes_授权认证_RBAC_静态Pod网关apiserver底层的RBAC授权的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 鲸会务大会管理系统为企业提供数字化会议管
- 下一篇: B轮融资成功,致谢今目标用户