Kubernetes K8S之鑒權概述與RBAC詳解

K8S認證與授權

認證「Authentication」

認證有如下幾種方式：

1、HTTP Token認證：通過一個Token來識別合法用戶，

HTTP Token的認證是用一個很長的特殊編碼方式的并且難以被模仿的字串來表達客戶的一種方式，每一個Token對應一個用戶名，存盤在API Server能訪問的檔案中，當客戶端發起API呼叫請求時，需要在HTTP Header里放入Token，

2、HTTP Base認證：通過用戶名+密碼的方式認證

用戶名:密碼用base64演算法進行編碼后的字串放在HTTP Request中的Heather Authorization 域里發送給服務端，服務端收到后進行解碼，獲取用戶名和密碼，

3、最嚴格的HTTPS證書認證：基于CA根證書簽名的客戶端身份認證方式

授權「Authorization」

認證只是確認通信的雙方都是可信的，可以相互通信，而授權是確定請求方有哪些資源的權限，API Server目前支持如下幾種授權策略（通過API Server的啟動引數 --authorization-mode 設定）

AlwaysDeny：表示拒絕所有請求，僅用于測驗
AlwaysAllow：表示允許所有請求，如果有集群不需要授權流程，則可以采用該策略
Node：節點授權是一種特殊用途的授權模式，專門授權由 kubelet 發出的 API 請求
Webhook：是一種 HTTP 回呼模式，允許使用遠程 REST 端點管理授權
ABAC：基于屬性的訪問控制，表示使用用戶配置的授權規則對用戶請求進行匹配和控制
RBAC：基于角色的訪問控制，默認使用該規則

RBAC授權模式

RBAC（Role-Based Access Control）基于角色的訪問控制，在Kubernetes 1.5 中引入，現為默認標準，相對其他訪問控制方式，擁有如下優勢：

1、對集群中的資源和非資源均擁有完整的覆寫

2、整個RBAC完全由幾個API物件完成，同其他API物件一樣，可以用kubectl或API進行操作

3、可以在運行時進行操作，無需重啟API Server

RBAC API型別

RBAC API 所宣告的四種頂級型別【Role、ClusterRole、RoleBinding 和 ClusterRoleBinding】，用戶可以像與其他 API 資源互動一樣，（通過 kubectl API 呼叫等方式）與這些資源互動，

Role 和 ClusterRole

在 RBAC API 中，一個角色包含一組相關權限的規則，權限是純粹累加的（不存在拒絕某操作的規則），即只能給權限累加，不存在給了XX權限，然后去掉XX01權限的情況，角色可以用 Role 來定義到某個命名空間（namespace）上，或者用 ClusterRole 來定義到整個集群作用域（所有namespace），

一個 Role 只可以用來對某一命名空間中的資源賦予訪問權限，

Role示例：

定義到名稱為 “default” 的命名空間，可以用來授予對該命名空間中的 Pods 的讀取權限：

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: Role
3 metadata:
4   name: pod-reader
5   namespace: default
6 rules:
7 - apiGroups: [""] # "" 指定核心 API 組
8   resources: ["pods"]
9   verbs: ["get", "watch", "list"]

ClusterRole 可以授予的權限和 Role 相同，但是因為 ClusterRole 屬于集群范圍，所以它也可以授予以下訪問權限：

集群范圍資源（比如 nodes訪問）
非資源端點（比如 “/healthz” 訪問）
跨命名空間訪問的有名稱空間作用域的資源（如 Pods），比如運行命令kubectl get pods --all-namespaces 時需要此能力

ClusterRole示例

可用來對某特定命名空間下的 Secrets 的讀取操作授權，或者跨所有名稱空間執行授權（取決于它是如何系結的）：

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4   name: secret-reader
5   # 此處的 "namespace" 被省略掉是因為 ClusterRoles 是沒有命名空間的，
6 rules:
7 - apiGroups: [""]
8   resources: ["secrets"]
9   verbs: ["get", "watch", "list"]

RoleBinding 和 ClusterRoleBinding

角色系結（RoleBinding）是將角色中定義的權限賦予一個用戶或者一組用戶，它包含若干主體【subjects】（users、groups或 service accounts）的串列和對這些主體所獲得的角色參考，

可以使用 RoleBinding 在指定的命名空間中執行授權，或者在集群范圍的命名空間使用 ClusterRoleBinding 來執行授權，

一個 RoleBinding 可以參考同一的命名空間中的 Role，

RoleBinding示例

將 “pod-reader” 角色授予在 “default” 命名空間中的用戶 “jane”；這樣，用戶 “jane” 就具有了讀取 “default” 命名空間中 pods 的權限，

在下面的例子中，角色系結使用 roleRef 將用戶 “jane” 系結到前文創建的角色 Role，其名稱是 pod-reader，

 1 apiVersion: rbac.authorization.k8s.io/v1
 2 # 此角色系結，使得用戶 "jane" 能夠讀取 "default" 命名空間中的 Pods
 3 kind: RoleBinding
 4 metadata:
 5   name: read-pods
 6   namespace: default
 7 subjects:
 8 - kind: User
 9   name: jane # 名稱大小寫敏感
10   apiGroup: rbac.authorization.k8s.io
11 roleRef:
12   kind: Role #this must be Role or ClusterRole
13   name: pod-reader # 這里的名稱必須與你想要系結的 Role 或 ClusterRole 名稱一致
14   apiGroup: rbac.authorization.k8s.io

roleRef 里的內容決定了實際創建系結的方法，kind 可以是 Role 或 ClusterRole，name 是你要參考的 Role 或 ClusterRole 的名稱，

RoleBinding 也可以參考 ClusterRole，這可以允許管理者在整個集群中定義一組通用的角色，然后在多個命名空間中重用它們，

RoleBinding示例2

下面的例子，RoleBinding 參考的是 ClusterRole， “dave” （subjects區分大小寫）將只可以讀取在”development” 名稱空間（ RoleBinding 的命名空間）中的”secrets” ，

 1 apiVersion: rbac.authorization.k8s.io/v1
 2 # 這個角色系結允許 "dave" 用戶在 "development" 命名空間中有讀取 secrets 的權限， 
 3 kind: RoleBinding
 4 metadata:
 5   name: read-secrets
 6   namespace: development # 這里只授予 "development" 命名空間的權限，
 7 subjects:
 8 - kind: User
 9   name: dave # 名稱區分大小寫
10   apiGroup: rbac.authorization.k8s.io
11 roleRef:
12   kind: ClusterRole
13   name: secret-reader
14   apiGroup: rbac.authorization.k8s.io

最后，ClusterRoleBinding 可用來在集群級別并對所有命名空間執行授權，

ClusterRoleBinding示例

 1 apiVersion: rbac.authorization.k8s.io/v1
 2 # 這個集群角色系結允許 "manager" 組中的任何用戶讀取任意命名空間中 "secrets"，
 3 kind: ClusterRoleBinding
 4 metadata:
 5   name: read-secrets-global
 6 subjects:
 7 - kind: Group
 8   name: manager # 名稱區分大小寫
 9   apiGroup: rbac.authorization.k8s.io
10 roleRef:
11   kind: ClusterRole
12   name: secret-reader
13   apiGroup: rbac.authorization.k8s.io

當我們創建binding后，則不能修改binding所參考的Role或ClusterRole，嘗試修改會導致驗證錯誤；如果要改變binding的roleRef，那么應該洗掉該binding物件并且創建一個新的用來替換原來的，

Referring to resources【資源參考】

Kubernetes集群內一些資源一般以其名稱字串來表示，這些字串一般會在API的URL地址中出現；同時某些資源也會包含子資源，例如pod的logs資源就屬于pods的子資源，API中URL樣例如下：

GET /api/v1/namespaces/{namespace}/pods/{name}/log

在這種情況下，”pods” 是有名稱空間的資源，而 “log” 是 pods 的子資源，在 RBAC 角色中，使用”/“分隔資源和子資源，

允許一個主體（subject）要同時讀取 pods 和 pod logs，你可以這么寫：

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: Role
3 metadata:
4   namespace: default
5   name: pod-and-pod-logs-reader
6 rules:
7 - apiGroups: [""]
8   resources: ["pods", "pods/log"]
9   verbs: ["get", "list"]

對于某些請求，也可以通過 resourceNames 串列按名稱參考資源，

例如：在指定時，可以將請求型別限制到資源的單個實體，限制只可以 “get” 和 “update” 到單個configmap，則可以這么寫：

 1 apiVersion: rbac.authorization.k8s.io/v1
 2 kind: Role
 3 metadata:
 4   namespace: default
 5   name: configmap-updater
 6 rules:
 7 - apiGroups: [""]
 8   resources: ["configmaps"]
 9   resourceNames: ["my-configmap"]
10   verbs: ["update", "get"]

需要注意的是，create 請求不能被 resourceName 限制，因為在鑒權時還不知道物件名稱，另一個例外是 deletecollection，

Referring to subjects【主體參考】

RoleBinding或ClusterRoleBinding系結一個role到主體（subjects），主體（subjects）可以是groups，users或ServiceAccounts，

Kubernetes將用戶名表示為字串，這些可以是：普通名稱，比如“alice” ；郵件風格的名字，比如“[email protected]” ；或表示為字串的數字用戶id，

注意：前綴 system: 是保留給Kubernetes系統使用的，因此應該確保不會出現名稱以system: 開頭的用戶或組，除了這個特殊的前綴，RBAC授權系統不要求用戶名使用任何格式，

ServiceAccounts具有前綴為system:serviceaccount: 的名稱，屬于具有前綴為system:serviceaccounts:的名稱的組，

RoleBinding的示例

下面的示例只是展示 RoleBinding 中 subjects 的部分，

用戶的名稱為 “[email protected]” ：

1 subjects:
2 - kind: User
3   name: "[email protected]"
4   apiGroup: rbac.authorization.k8s.io

組的名稱為 “frontend-admins” ：

1 subjects:
2 - kind: Group
3   name: "frontend-admins"
4   apiGroup: rbac.authorization.k8s.io

默認service account在 kube-system 命名空間中：

1 subjects:
2 - kind: ServiceAccount
3   name: default
4   namespace: kube-system

在名稱為 “qa” 命名空間中所有的服務賬號：

1 subjects:
2 - kind: Group
3   name: system:serviceaccounts:qa
4   apiGroup: rbac.authorization.k8s.io

在任意名稱空間的所有service accounts：

1 subjects:
2 - kind: Group
3   name: system:serviceaccounts
4   apiGroup: rbac.authorization.k8s.io

所有認證過的用戶（版本 1.5+）：

1 subjects:
2 - kind: Group
3   name: system:authenticated
4   apiGroup: rbac.authorization.k8s.io

所有未認證的用戶（版本 1.5+）：

1 subjects:
2 - kind: Group
3   name: system:unauthenticated
4   apiGroup: rbac.authorization.k8s.io

所有用戶（版本 1.5+）：

1 subjects:
2 - kind: Group
3   name: system:authenticated
4   apiGroup: rbac.authorization.k8s.io
5 - kind: Group
6   name: system:unauthenticated
7   apiGroup: rbac.authorization.k8s.io

準入控制

準入控制是API Server的插件集合，通過添加不同的插件，實作額外的準入控制規則，甚至于API Server的一些主要的功能都需要通過Admission Controllers實作，比如：ServiceAccount，

查看哪些插件是默認啟用的：

kube-apiserver -h | grep enable-admission-plugins

在 1.17 中，它們是：

1 NamespaceLifecycle, LimitRanger, ServiceAccount, 
2 TaintNodesByCondition, Priority, DefaultTolerationSeconds, 
3 DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, 
4 MutatingAdmissionWebhook, ValidatingAdmissionWebhook, RuntimeClass, ResourceQuota

部分插件功能：

NamespaceLifecycle

該準入控制器禁止在一個正在被終止的 Namespace 中創建新物件，并確保使用不存在的 Namespace 的請求被拒絕，該準入控制器還會禁止洗掉三個系統保留的命名空間，即 default、kube-system 和 kube-public，

洗掉 Namespace 會觸發洗掉該命名空間中所有物件（pod、services 等）的一系列操作，為了確保這個程序的完整性，我們強烈建議啟用這個準入控制器，

LimitRanger

該準入控制器會觀察傳入的請求，并確保它不會違反 Namespace 中 LimitRange 物件列舉的任何約束，

ServiceAccount

該準入控制器實作了 serviceAccounts 的自動化，如果打算使用 Kubernetes 的 ServiceAccount 物件，強烈建議您使用這個準入控制器，

ResourceQuota

該準入控制器會監測傳入的請求，并確保它不違反任何一個 Namespace 中的 ResourceQuota 物件中列舉出來的約束，

Kubernetes K8S之鑒權RBAC詳解