一文讀懂k8s rbac 權限驗證

自我認爲的k8s三大難點：權限驗證，覆蓋網絡，各類證書。

 

今天就說一下我所理解的權限驗證rbac。

 

咱不說rbac0，rbac1，rbac2，rbac3。咱就說怎麼控制權限就行。

 

 

1、前言

1，反正RBAC模型是很是牛逼的。如今運用的很是廣。官方的解釋是（Role-Based Access Control：基於角色的訪問控制）。

2，簡單抽象的歸納就是：誰 是否能夠對 什麼東西 進行 怎麼樣 的訪問操做。

3，這樣就組成了訪問權限的三個重要的東西：誰    什麼東西    怎麼樣

 

好比：    老闆 能夠對 我 進行 開除 的決定。    哈哈！這個有點。。。

                 我 還不能對 老闆 的決定進行 反對 。

                 而後 我 就被 公司人事 開除了。

 

抱拳  抱拳  抱拳    水平有限！！！

 

 

2、RBAC組成

 

在RBAC模型裏面，有3個基礎組成部分，分別是：用戶、角色和權限。

 

• User（用戶）：每一個用戶都有惟一的UID識別，並被授予不一樣的角色
• Role（角色）：不一樣角色具備不一樣的權限
• Permission（權限）：訪問權限
• 用戶-角色映射：用戶和角色之間的映射關係
• 角色-權限映射：角色和權限之間的映射

 

它們之間的關係以下圖所示：

 

 

例以下圖：

• 管理員和普通用戶被授予不一樣的權限
• 普通用戶只能去修改和查看我的信息
• 而不能建立建立用戶和凍結用戶
• 而管理員因爲被授予全部權限，因此能夠作全部操做

 

 

2、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