一 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