一 RBAC
1.1 RBAC受權
基於角色的訪問控制(RBAC)是一種基於我的用戶的角色來管理對計算機或網絡資源的訪問的方法。
RBAC使用rbac.authorization.k8s.io API組來推進受權決策,容許管理員經過Kubernetes API動態配置策略。
使用--authorization-mode=RBAC開啓RBAC受權模塊功能。
RBAC API定義了四個資源對象用於描述RBAC中用戶和資源之間的鏈接權限:
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
二 角色
2.1 Role 和 ClusterRole
RBAC API聲明瞭四種類型。
在RBAC API中,角色包含表示一組權限的規則。權限都是疊加的,沒有deny規則。附加的(沒有「拒絕」規則)。可使用參數role在一個namespace中定義一個角色,或者在集羣範圍內使用ClusterRole定義集羣角色。
一個Role只能用於授予對單個命名空間內的資源的訪問權限。
示例1:
1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: Role
3 metadata:
4 namespace: default
5 name: pod-reader
6 rules:
7 - apiGroups: [""] # "" indicates the core API group
8 resources: ["pods"]
9 verbs: ["get", "watch", "list"]
解釋:該Role授予對「default」命名空間中的pod的讀取權限。
一個ClusterRole可用於授予與一個Role相同的權限,同時因爲它們是羣集範圍的,所以它們還可用於授予對如下內容的訪問權限:
- 集羣範圍的資源(如nodes);
- non-resource endpoints(如「/healthz」);
- 跨全部命名空間(可經過kubectl get pods --all-namespaces查看)的命名空間資源(如pods)。
示例2:
1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4 # "namespace" omitted since ClusterRoles are not namespaced
5 name: secret-reader
6 rules:
7 - apiGroups: [""]
8 resources: ["secrets"]
9 verbs: ["get", "watch", "list"]
解釋:該ClusterRole可用於授予對任何特定命名空間或全部命名空間中的secrets資源的讀訪問權限。
2.2 RoleBinding 和 ClusterRoleBinding
角色綁定將角色中定義的權限授予用戶或用戶組。它包含由users,groups,或service accounts組成的列表,以及對所授予角色的引用。能夠在具備個RoleBinding集羣名稱或具備一個ClusterRoleBinding範圍內授予權限。
一個RoleBinding能夠引用同一名稱空間中的Role。
示例:
1 apiVersion: rbac.authorization.k8s.io/v1
2 # This role binding allows "jane" to read pods in the "default" namespace.
3 kind: RoleBinding
4 metadata:
5 name: read-pods
6 namespace: default
7 subjects:
8 - kind: User
9 name: jane # Name is case sensitive
10 apiGroup: rbac.authorization.k8s.io
11 roleRef:
12 kind: Role #this must be Role or ClusterRole
13 name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
14 apiGroup: rbac.authorization.k8s.io
解釋:該RoleBinding將「pod-reader」角色授予「default」命名空間中的用戶「jane」,同時容許「jane」讀取「default」命名空間中的pod。
該RoleBinding 使用roleRef將用戶「jane」綁定到Role上面建立的名稱pod-reader。
2.3 默認角色
API服務器建立了一組默認ClusterRole和ClusterRoleBinding對象。其中格式爲system:前綴的表示該資源由系統基礎設施所擁有。手動修改該類資源可能致使集羣功能異常,若system:node的ClusterRole,定義了kubelet的權限。
提示:全部默認羣集角色和角色綁定都標有kubernetes.io/bootstrapping=rbac-defaults。
三 角色相關命令
3.1 建立角色
1 [root@master ~]# kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
2 role.rbac.authorization.k8s.io/pod-reader created
解釋:建立一個名爲「pod-reader」的Role,容許用戶在pod上執行「get」,「watch」和「list」。
1 [root@master ~]# kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
解釋:建立一個指定了namespace爲anotherpod的名爲「pod-reader」的Role。
1 [root@master ~]# kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
解釋:建立一個指定apiGroups的名爲「foo」的Role,容許用戶在replicasets.apps上執行「get」,「watch」和「list」。
1 [root@master ~]# kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
解釋:建立一個指定子資源權限的名爲「foo」的Role,容許用戶在pods上執行「get」,「watch」和「list」。
3.2 建立集羣角色
1 [root@master ~]# kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
解釋:建立一個名爲「pod-reader」的clusterrole,容許用戶在pod上執行「get」,「watch」和「list」。
1 [root@master ~]# kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
解釋:建立一個指定了resourceNames名爲「pod-reader「的clusterrole,並容許執行「get」。
1 [root@master ~]# kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
解釋:建立一個指定apiGroups的名爲「foo」的clusterrole,容許用戶在replicasets.apps上執行「get」,「watch」和「list」。
1 [root@master ~]# kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
解釋:建立一個指定子資源權限的名爲「foo」的clusterrole,容許用戶在pods上執行「get」,「watch」和「list」。
1 [root@master ~]# kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
解釋:建立一個指定了non-resource路徑名爲「pod-reader「的clusterrole,並容許執行「get」。
3.3 權限和角色綁定
1 [root@master ~]# kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
解釋:在acme的namespace中,將admin的clusterrole和bob用戶進行綁定。
1 [root@master ~]# kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
解釋:在acme的namespace中,將view的clusterrole和myapp服務帳號進行綁定。
1 [root@master ~]# kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
解釋:在acme的namespace中,將view的clusterrole和myapp的namespace中的服務帳號進行綁定。
3.4 權限和集羣角色綁定
1 [root@master ~]# kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
解釋:在整個集羣中,將cluster-admin的clusterrole和root用戶進行綁定。
1 [root@master ~]# kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
解釋:在整個集羣中,將system:node-proxier的clusterrole和system:kube-proxy用戶進行綁定。
1 [root@master ~]# kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
解釋:在整個集羣中,將view的clusterrole和myapp中的acme服務帳戶進行綁定。
提示:roles和clusterroles的區別在於roles只能對某個命令空間內的資源定義權限。而集羣角色定義的權限都是針對整個集羣的命名空間的。
更多RBAC參考:https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole
3.4 相關對比
ClusterRole和ClusterRoleBinding是針對整個Cluster範圍內有效的,不管用戶或資源所在的namespace是什麼;
Role和RoleBinding的做用範圍是侷限在某個k8s namespace中的。
kubernetes在安裝之初就已經生成了許多role、rolebinding、clusterrole和clusterrolebinding,它們也是屬於kubernetes資源的一部分,可經過get、describe等命令查看,以下:
1 [root@master ~]# kubectl get role -n kube-system
1 [root@master ~]# kubectl describe role extension-apiserver-authentication-reader -n kube-system