自我認為的k8s三大難點：權限驗證，覆蓋網絡，各種證書。
今天就說一下我所理解的權限驗證rbac。
咱不說rbac0，rbac1，rbac2，rbac3。咱就說怎么控制權限就行。
一、前言
1，反正RBAC模型是非常牛逼的。現在運用的非常廣。官方的解釋是（Role-Based Access Control：基於角色的訪問控制）。
2，簡單抽象的概括就是：誰 是否可以對 什么東西 進行 怎么樣 的訪問操作。
3，這樣就組成了訪問權限的三個重要的東西：誰 什么東西 怎么樣
比如： 老板 可以對 我 進行 開除 的決定。 哈哈！這個有點。。。
我 還不能對 老板 的決定進行 反對 。
然后 我 就被 公司人事 開除了。
抱拳 抱拳 抱拳 水平有限！！！
二、RBAC組成
在RBAC模型里面，有3個基礎組成部分，分別是：用戶、角色和權限。
- User（用戶）：每個用戶都有唯一的UID識別，並被授予不同的角色
- Role（角色）：不同角色具有不同的權限
- Permission（權限）：訪問權限
- 用戶-角色映射：用戶和角色之間的映射關系
- 角色-權限映射：角色和權限之間的映射
它們之間的關系如下圖所示：
例如下圖：
- 管理員和普通用戶被授予不同的權限
- 普通用戶只能去修改和查看個人信息
- 而不能創建創建用戶和凍結用戶
- 而管理員由於被授予所有權限，所以可以做所有操作
二、K8s RBAC
RBAC API 聲明了四種 Kubernetes 對象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。
你可以用kubectl get 獲取到，Role、RoleBinding需要加上namespace。
我們先上一張圖，咱們圍繞這張圖解釋。
接下來我們一個一個的說。
2.1 Role 和 ClusterRole
role和ClusterRole可以看做是一個角色。
比如：
領導和員工是兩個不同的角色
資源就是一只筆
操作就是簽字
那么領導和員工兩個不同的角色所簽下去的字的 效果就不一樣了。這就是角色所帶來的不同權限。
2.1.1 Role
Role 就是用來在某一個namespace內設置訪問權限。創建Role的時候，必須指定namespaces。
下面是一個位於 "default" 名字空間的 Role 的示例，可用來授予對 pods 的讀訪問權限：
apiVersion: rbac.authorization.k8s.io/v1 # api
kind: Role # 資源名稱
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # apiGroups 就是api資源組，你kubectl get apiservice 就可以看到集群所有的api組
resources: ["pods"] # 就是k8s資源的名稱。kubectl api-resources 這個命令可以查看到，第一列是資源名稱，就是可以寫在這里的。
# 第二列是簡寫，kubectl get 后面的可以簡寫。
# 第三列是APIGROUP組
# 第四列是是否屬於NAMESPACED資源，就是你可以在ns下面看到的資源
# 第五列是kind的時候寫的名稱
# 資源還分子資源，后期會寫一篇專門的文章介紹
verbs: ["get", "watch", "list"] # 定義動作，get是查看權限，update是更新權限。。。
2.1.2 ClusterRole
ClusterRole 就是用來在集群內設置訪問權限。ClusterRole不用固定在一個namespaces。
這兩種資源的名字不同（Role 和 ClusterRole）是因為 Kubernetes 對象要么是namespaces作用域的，要么是集群作用域的， 不可兩者兼具。
下面是一個 ClusterRole 的示例，可用來為任一特定名字空間中的 Secret 授予讀訪問權限， 或者跨名字空間的訪問權限（取決於該角色是如何綁定的）：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略，因為 ClusterRoles 不受名字空間限制
name: secret-reader
rules:
- apiGroups: [""]
# 在 HTTP 層面，用來訪問 Secret 對象的資源的名稱為 "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
2.2 、RoleBinding 和 ClusterRoleBinding
RoleBinding 和 ClusterRoleBinding 是用來 把用戶和角色關聯起來的。
角色綁定（Role Binding）是將角色中定義的權限賦予一個或者一組用戶。
它包含若干 主體（用戶、組或服務賬戶）的列表和對這些主體所獲得的角色的引用。
RoleBinding 在指定的名字空間中執行授權，而 ClusterRoleBinding 在集群范圍執行授權。
2.2.1 RoleBinding
一個 RoleBinding 可以綁定同一的namespaces中的任何 一個Role。
或者，一個 RoleBinding 可以引用某 ClusterRole ，並將該 ClusterRole 綁定到 RoleBinding 所在的namespaces。
下面的例子中的 RoleBinding 將 "pod-reader" Role 授予在 "default" 名字空間中的用戶 "jane"。
這樣，用戶 "jane" 就具有了讀取 "default" 名字空間中 pods 的權限。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色綁定允許 "jane" 讀取 "default" 名字空間中的 Pods
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# 你可以指定不止一個“subject（主體）”
- kind: User
name: jane # "name" 是不區分大小寫的
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" 指定與某 Role 或 ClusterRole 的綁定關系
kind: Role # 此字段必須是 Role 或 ClusterRole
name: pod-reader # 此字段必須與你要綁定的 Role 或 ClusterRole 的名稱匹配
apiGroup: rbac.authorization.k8s.io
RoleBinding 也可以引用 ClusterRole，以將對應 ClusterRole 中定義的訪問權限授予 RoleBinding 所在名字空間的資源。
這種引用使得你可以跨整個集群定義一組通用的角色， 之后在多個名字空間中復用。
例如，盡管下面的 RoleBinding 引用的是一個 ClusterRole，
"dave"（這里的主體， 不區分大小寫）只能訪問 "development" 名字空間中的 Secrets 對象，
因為 RoleBinding 所在的名字空間（由其 metadata 決定）是 "development"。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色綁定使得用戶 "dave" 能夠讀取 "development" 名字空間中的 Secrets
# 你需要一個名為 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
name: read-secrets
# RoleBinding 的名字空間決定了訪問權限的授予范圍。
# 這里隱含授權僅在 "development" 名字空間內的訪問權限。
namespace: development
subjects:
- kind: User
name: dave # 'name' 是不區分大小寫的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
2.2.2 ClusterRoleBinding
如果你希望將某 ClusterRole 綁定到集群中所有名字空間，你要使用 ClusterRoleBinding。
要跨整個集群完成訪問權限的授予，你可以使用一個 ClusterRoleBinding。
下面的 ClusterRoleBinding 允許 "manager" 組內的所有用戶訪問任何名字空間中的 Secrets。
apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色綁定允許 “manager” 組中的任何人訪問任何名字空間中的 secrets
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # 'name' 是不區分大小寫的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
其實關於k8s rbac還有很多需要注意的地方，
大家可以仔細的把官方文檔讀一遍。
讀完了其實你對k8s 的rbac的理解就已經非常厲害了。
官方地址：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
大家可以參考我的另一篇文檔，實際運用了一下k8s rbac：https://www.cnblogs.com/fanfanfanlichun/p/14989454.html