基礎概念
k8s中的所有API對象都保存在etcd中 對這些API對象的操作必須通過APIServer進行訪問其中一個重要的原因就是必須通過APIserver進行授權工作
Role：角色,它其實是一組規則,定義了一組對 Kubernetes API 對象的操作權限
Role 對象指定了它能產生作用的 Namepace 是：mynamespace
Namespace 是 Kubernetes 項目里的一個邏輯管理單位.不同 Namespace 的 API 對象,在通過 kubectl 命令進行操作的時候,是互相隔離開的
Subject：被作用者,既可以是“人”,也可以是“機器”,也可以使你在 Kubernetes 里定義的“用戶”
RoleBinding：定義了“被作用者”和“角色”的綁定關系
角色和綁定的組合
只要是RoleBinding 作用域就只是在定義RoleBinding的名稱空間中
只要是ClusterRoleBinding 作用域就是整個集群范圍(所有名稱空間)
Role 只是在當前Role所在的名稱空間中定義了一個角色 其它名稱空間下並不會出現這個Role
Role和ClusterRoleBinding表示在Role所在的名稱空間中有一個 能操作整個集群資源的角色 在所有名稱空間中有效 Role升級為ClusterRole
ClusterRole 表示同時整個集群(每個名稱空間)中定義了一個角色 所有名稱空間下都有一個相同名稱的Role
ClusterRole和RoleBinding 只在RoleBinding的名稱空間中有效 ClusterRole降級為Role
User和ServiceAccount的授權
Kubernetes 里的“User”,也就是“用戶”,只是一個授權系統里的邏輯概念,它需要通過外部認證服務.比如 Keystone,來提供.或者,你也可以直接給 APIServer 指定一個用戶名、密碼文件.那么 Kubernetes 的授權系統,就能夠從這個文件里找到對應的“用戶”了 Uer在k8s中使用的比較少
Kubernetes 還擁有“用戶組”（Group）的概念,也就是一組“用戶”的意思
Kubernetes 負責管理的“內置用戶",正是ServiceAccount 在k8s中一般使用ServiceAccount來代替User
serviceAccount示例流程:
1.創建一個ServiceAccount資源
2.創建一個role資源
3.創建一個rolebinding資源綁定ServiceAccount和role(自動生成對應的secret)
kubectl describe secret secretobject 查看token信息
k8s在把ServiceAccount和Role進行綁定的時候會自動創建一個Secret對象
這個 Secret,就是這個 ServiceAccount 對應用來跟 APIServer 進行交互的授權文件,我們一般稱它為：Token.Token 文件的內容一般是證書或者密碼,它以一個 Secret 對象的方式保存在 Etcd當中 這時候用戶的 Pod,就可以聲明使用這個 ServiceAccount
如果一個 Pod 沒有聲明 serviceAccountName,Kubernetes 會自動在它的Namespace下創建一個名叫 default 的默認ServiceAccount,然后分配給這個 Pod.但在這種情況下,這個默認 ServiceAccount 並沒有關聯任何 Role.也就是說,此時它有訪問 APIServer 的絕大多數權限.當然,這個訪問所需要的 Token,還是默認ServiceAccount 對應的 Secret 對象為它提供的
在k8s中最普遍的是ServiceAccount,所以Role + RoleBinding + ServiceAccount 的權限分配方式是編寫和安裝各種插件的時候,會經常用到這個組合.