一文讀懂k8s rbac 許可權驗證

春寒知冬冷發表於2021-07-23
K8S

自我認為的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

相關文章