一、簡介
基於角色的訪問控制（“RBAC”）
http://docs.kubernetes.org.cn/80.html
(1)
Kubernetes的授權是基於插件形式的，常用的授權插件有以下幾種：
- Node：node節點授權
- ABAC：基於屬性的訪問控制
- RBAC：基於角色的訪問控制
- Webhook：自定義http回調方法
RBAC：http://docs.kubernetes.org.cn/148.html
基於角色的訪問控制：如圖，先讓一個用戶（Users）扮演一個角色（Role），讓角色(Role)擁有權限，從而讓用戶擁有這樣的權限，然后在授權機制當中，只需要將權限授予某個角色，此時用戶將獲取對應角色的權限，從而實現角色的訪問控制；
(2)Role和ClusterRole
Role是一系列的權限的集合，例如一個Role可以包含讀取 Pod 的權限和列出 Pod 的權限， ClusterRole 跟 Role 類似，但是可以在集群中全局使用。
Role只能授予單個namespace 中資源的訪問權限。
ClusterRole授權 >= Role授予（與Role類似），但ClusterRole屬於集群級別對象：
-
- 集群范圍（cluster-scoped）的資源訪問控制（如：節點訪問權限）
- 非資源類型（如“/ healthz”）
- 所有namespaces 中的namespaced 資源（如 pod）
(3)RoleBinding和ClusterRoleBinding
RoleBinding是將Role中定義的權限授予給用戶或用戶組。它包含一個subjects列表(users，groups ，service accounts)，並引用該Role，Role有了權限，用戶也就有了權限。RoleBinding在某個namespace 內授權，ClusterRoleBinding適用在集群范圍內使用。
RoleBinding可以引用相同namespace下定義的Role。
Role和ClusterRole、RoleBinding和ClusterRoleBinding關系如下圖：
(4)
使用RoleBinding去綁定ClusterRole：
如果有10個名稱空間，每個名稱空間都需要一個管理員，而這些管理員的權限都是一致的。那么此時需要去定義這樣的管理員，使用RoleBinding就需要創建10個Role，這樣顯得很麻煩。為此當使用RoleBinding去綁定一個ClusterRole時，該User僅僅擁有對當前名稱空間的集群操作權限，而不是擁有所有名稱空間的權限，所以此時只需要創建一個ClusterRole代替掉10個Role就解決了以上的需求。
二、RBAC應用
(1)Role --> User -->Rolebinding
用法：
使用kubectl create進行創建角色(role)，指定角色名稱，--verb指定權限，--resource指定資源或者資源組，--dry-run：此模式不會真的創建；
a、
[root@master ~]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #先用--dry-run模式看一下role的定義
b、生成資源定義清單
[root@master ~]# cd manifests/
#導出yaml文件，稍微編輯一下就能用了
[root@master manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml >role-demo.yaml
[root@master manifests]# vim role-demo.yaml
c、創建
(2)RoleBinding角色綁定
創建方法：
使用kubectl create進行創建角色綁定，指定角色綁定的名稱，--role|--clusterrole指定綁定哪個角色，--user指定哪個用戶；
a、導出rolebinding資源定義清單文件
[root@master manifests]# kubectl explain role #查看資源定義清單字段
[root@master manifests]# kubectl explain rolebinding #查看資源定義清單字段
[root@master manifests]# kubectl create rolebinding magedu-read-pods --role=pods-reader --user=magedu --dry-run -o yaml > rolebinding-demo.yaml
b、創建，將權限授權給用戶magedu
[root@master manifests]# kubectl apply -f rolebinding-demo.yaml
c、可見magedu已經綁定到了pods-reader角色上了；
d、切換用戶訪問
現在magedu已經有權限訪問了；
以上操作role和rolebinding都是只對當前名稱空間生效；
[root@master ~]# kubectl config use-context kubernetes-admin@kubernetes #切換回kubernetes-admin用戶
(2)ClusterRole-->ClusterRoleBinding-->User
[root@master manifests]# kubectl explain clusterrole #查看資源定義清單字段
[root@master manifests]# kubectl explain clusterrolebinding #查看資源定義清單字段
a、導出clusterrole的資源定義清單文件
[root@master manifests]# kubectl create clusterrole cluster-read --verb=get,list,watch --resource=pods -o yaml >clusterrole-demo.yaml
[root@master manifests]# vim clusterrole-demo.yaml
b、創建clusterrole
[root@master manifests]# kubectl apply -f clusterrole-demo.yaml
此時我們可以新建一個Linux系統賬戶，然后在這個系統賬戶下，將kubernetes的用戶切換到magedu下，隨后對magedu賦予clusterrole的權限；
c、此時我們刪除之前創建的rolebinding 解除magedu的權限；
可見此時magedu已經沒有了權限；
d、創建clusterrolebinding
導出yaml資源定義清單文件：
[root@master ~]# kubectl create clusterrolebinding magedu-read-all-pods --clusterrole=cluster-read --user=magedu --dry-run -o yaml >manifests/clusterrolebinding-demo.yaml
[root@master manifests]# vim clusterrolebinding-demo.yaml
創建，將magedu綁定到clusterrole：
[root@master manifests]# kubectl apply -f clusterrolebinding-demo.yaml
查看，可見已經綁定到集群角色：
e、此時我們切換到系統用戶為ik8s的窗口，並且kubernetes的用戶為maedu
查看其他namespace的pod, 也是可以的：
但是，現在是不能刪pod的，因為沒有授權：
以上可見，對用戶magedu進行集群角色綁定，用戶magedu將會獲取對集群內所有資源的(namespace)對應權限。
(3)clusterrole --> rolebinding --> user
將maedu通過rolebinding到集群角色clusterrole中，此時，magedu僅作用於當前名稱空間的所有pods資源的權限;
a、刪除之前的clusterrolebinding
b、導出yaml資源定義清單文件
[root@master manifests]# kubectl create rolebinding magedu-read-pods --clusterrole=cluster-read --user=magedu --dry-run -o yaml >rolebinding-clusterrole-dmeo.yaml
[root@master manifests]# vim rolebinding-clusterrole-dmeo.yaml
c、創建rolebinding，將magedu綁定到clusterrole
查看rolebinding
可見magedu已經綁定到集群角色clusterrole上了；
d、此時切換到系統用戶ik8s的窗口
可見magedu可以訪問當前namespace的pod，但是不能訪問其他namespace的pod;
因為這種綁定方式，clusterrole是被降級的；
(4)RBAC的三種授權訪問方式
RBAC不僅可以對user進行訪問權限的控制，還可以通過group和serviceaccount進行訪問權限控制。user即單個用戶，group是對一個組內的user進行授權；
上一節學習了Pod可以通過 spec.serviceAccountName來定義其是以某個serviceaccount的身份進行運行，當我們通過RBAC對serviceaccount進行訪問授權時，就可以實現Pod對其他資源的訪問權限進行控制。也就是說，當我們對serviceaccount進行rolebinding或clusterrolebinding，會使創建Pod擁有對應角色的權限和apiserver進行通信。