搞懂K8s的鑒權
前言
本文介紹K8s中的鑒權模塊。對其4種鑒權模式都進行了概述講解。結合例子著重對大家日常中使用最多的RBAC鑒權模式進行了說明。
鑒權概述
《搞懂K8s認證》中，我們提到不論是通過kubectl客戶端還是REST請求訪問K8s集群，最終都需要經過API Server來進行資源的操作并通過Etcd。整個過程如下圖1所示，可以分成4個階段：
圖1 K8s API請求訪問過程
請求發起方進行K8s API請求，經過Authentication（認證）、Authorization（鑒權）、AdmissionControl（準入控制）三個階段的校驗，最后把請求轉化為對K8s對象的變更操作持久化至etcd中。
其中認證主要解決的是請求來源能否訪問的問題。即通過了認證，那么可以認為它是一個合法的請求對象。那么如何去決定請求對象能訪問哪些資源以及對這些資源能進行哪些操作，便是鑒權所要完成的事情了。
鑒權的最終目的，是區分請求對象，限定操作的影響范圍，讓其使用最小的權限完成自己所要進行操作，從而進一步保證安全。權限控制的劃分方式有許多種，K8s中提供了4種鑒權模式，分別為Node、ABAC、RBAC和Webhook。
默認情況下，我們可以從/etc/kubernates/manifests/kube-apiserver.yaml文件中查看apiserver啟動時認證模式，片段如圖2所示：
圖2 kube-apiserver的認證參數
其中可以使用的參數如表1所示：
表1 鑒權模塊參數標識表
參數配置 | 含義 | 一般的使用場景 |
--authorization-mode=ABAC | 使用基于屬性的訪問控制(ABAC) | 根據用戶的用戶名或者組名來控制其對集群資源的訪問權限，適用于較小的組織或開發團隊 |
--authorization-mode=RBAC | 使用基于角色的訪問控制(RBAC) | 自定義ServiceAccount，綁定資源根據角色來控制資源的訪問權限，適用于較大型的組織或者開發運維團隊 |
--authorization-mode=Webhook | 使用HTTP回調模式，允許你使用遠程REST端點管理鑒權 | 將鑒權角色交給外部服務進行處理，根據自身需求，定制和擴展鑒權策略，如自定義Webhook鑒權模塊對跨云平臺的應用進行集中的的訪問控制 |
--authorization-mode=Node | 針對kubelet發出的API請求執行鑒權 | 驗證節點身份，確保只有經過身份驗證且具有所需權限的Node才能連接到K8s集群 |
--authorization-mode=AlwaysDeny | 阻止所有請求 | 一般僅用作測試 |
--authorization-mode=AlwaysAllow | 允許所有請求 | 不需要API請求進行鑒權的場景 |
如圖2所示，可以同時配置多個鑒權模塊（多個模塊之間使用逗號分隔），排在靠前的模塊優先執行，任何模式允許或拒接請求，則立即返回該決定，并不會與其他鑒權模塊協商。
Node鑒權
Node鑒權是一種特殊用途的鑒權模式，旨在對kubelet發出API請求進行授權。Node鑒權允許kubelet執行API的操作分成讀和寫兩部分。讀取操作控制范圍為：services、endpoints、nodes、pods以及綁定到kubelet節點 Pod相關的secret、configmap、pvc和持久卷。寫入操作的范圍主要是節點和節點狀態、Pod和Pod狀態以及事件，若要限制kubelet只能修改自己的節點，則還需要在Apiserver啟動時，開啟NodeRestriction準入插件（見圖2第二個紅框）。
開啟Node鑒權模塊后，kubellet為了獲取授權，必須使用一個特定規則的憑據，如圖3所示：
圖3 kubelet的證書憑據
從圖中我們看到，kubelet使用了一個證書憑據，其中O=system:nodes表示其所在組，CN=system:node:paas-cnp-k8s-kce-01表示其用戶名，滿足了Node鑒權模塊要求的組名必須為system:nodes，用戶名必須為system:node:<nodeName>的要求。其中<nodeName>默認由hostname或kubelet --hostname-override選項提供指定，其必須與kubelet提供的主機名稱精確匹配。
system:nodes是K8s的內置用戶組，我們可以通過其默認的ClusterRoleBinding，如圖4所示：
圖4 system:nodes的ClusterRoleBinding內容
我們可以發現，它指示指向了system:node這個ClusterRole，并沒有subjects的內容，即其沒有綁定system:node:paas-cnp-k8s-kce-01用戶也沒有綁定system:nodes組。其正是因為K8s基于 Node鑒權模塊來限制kubelet只能讀取和修改本節點上的資源，并不是使用 RBAC來鑒權（涉及到部分RBAC的內容，下文會進行詳解）。
ABAC鑒權
基于屬性的訪問控制，K8s中可以表述將訪問策略授予用戶或者組。與RBAC不同的點在于，其策略是由任何類型的屬性（用戶屬性、資源屬性、對象、環境等）進行描述。
啟用ABAC模式，類似于圖2需要在apiserver啟動時指定--authorization-mode=ABAC以及--authorization-policy-file=<策略文件路徑> 。圖5是K8s官網給出的一個策略樣例文件：
圖5 ABAC策略實例文件內容
文件中每行都是一個JSON對象，其中版本控制屬性"apiVersion": "abac.authorization.kubernetes.io/v1beta1"和"kind": "Policy"可以理解成固定寫法，是被K8s本身所使用，便于以后進行版本控制和轉換。spec部分，其中user，來自于--token-auth-file的用戶字符串，其指定的user名稱必須與這個文件中的字符串相匹配；group，必須與經過身份驗證的用戶的一個組匹配， system:authenticated 匹配所有經過身份驗證的請求。 system:unauthenticated 匹配所有未經過身份驗證的請求。其他的匹配屬性，主要描述被訪問的訪問，分為資源屬性和非資源屬性（其具體定義可參見官網）。readonly，主要限制是否只允許對資源進行 get、list 和 watch 操作，非資源屬性只進行get操作。
例如：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}表示用戶alice可以對所有namespace下的所有資源進行任何操作；
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}表示用戶bob只能對namespace為projectCaribou的Pod進行list、get和watch操作。
對于ServiceAccount的ABAC管控。Service Account會自動生成一個ABAC用戶名，其格式為：system:serviceaccount:<namespace>:<serviceaccountname>，創建新的命名空間時，K8s會為我們在當前namespace下創建一個名為default的ServiceAccount，如果現在假定我們需要namespace為test名為default的ServiceAccount具有該namespace下的全部權限，則可以添加這樣一條規則：
{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:test:default","namespace":"test","resource":"*","apiGroup":"*"}}我們發現，ABAC雖然對用戶訪問進行了一定的劃分，但是如果添加了新的ABAC策略，則需要重啟API Server以使其生效，資源的訪問權限細粒度也只控制到了是否只讀，當用戶規模增大時，這是遠遠不能滿足需求的。對于較大組織的團隊進行更加細粒度的管控，就需要使用到K8s的RBAC鑒權模塊了。
RBAC鑒權
啟用RBAC鑒權，可以如圖2所示，在--authorization-mode的啟動參數中包含RBAC即可。相對于其他訪問控制方式，RBAC具有如下優勢：
- 對集群中的資源和非資源權限均有完整的覆蓋。
- RBAC由幾個API對象完成。同其他API對象一樣，可以用kubectl或API進行操作和調整，不必重新啟動ApiServer。
K8s的RBAC主要闡述解決了主體（subject）是什么角色的問題。其中主體就是K8s中的用戶，包含了常規用戶（User、Group，平時常用的kubectl命令都是普通用戶執行的）和服務賬戶（ServiceAccount，主要用于集群進程與K8s的API通信）。角色決定了能夠對資源進行什么樣的操作，RBAC中我們可以定義namespace級別的Role也可以定義集群級別的ClusterRole。最后K8s再通過RoleBinding和ClusterRoleBinding把用戶和角色的關系進行關聯綁定，其中RoleBinding既可以綁定Role也可以綁定ClusterRole，ClusterRole指定綁定ClusterRole，最終實現了不同用戶對不同資源進行特定操作的控制。Role針對特定的命名空間，ClusterRole在整個集群范圍內都生效，所以后者訪問范圍也更大，能夠限制訪問Node等資源。其關系圖如圖6所示：
圖6 RBAC整體關系圖
現在假設你所在部門使用名為rbac-team的命名空間工作，現在要為部署流水線創建一個新的ClusterRole名為deployment-clusterrole，且僅允許創建Deployment、StatefulSet、DaemonSet三種資源，同時在rbac-team這個命名空間下創建一個新的ServiceAccount名為cicd-test使用這個ClusterRole。K8s中我們可以使用kubectl客戶端或者API資源的方式來實現這個RBAC的功能。
Kubectl客戶端方式。
- 第一步，我們可以先執行命令：kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets 創建所需的ClusterRole，其中--verb代表可以執行的操作，--reasource代表授權操作的資源范圍；
- 第二步，執行命令：kubectl -n rbac-team create serviceaccount cicd-test創建要求的ServiceAccount；
- 第三步，限于rbac-test中綁定所需權限，執行命令：kubectl -n rbac-team create rolebinding cicd-rolebinding --clusterrole=deployment-clusterrole --serviceaccount=rbac-team:cicd-test，對新創建的ServiceAccount與我們的ClusterRole進行綁定。
Api資源的方式。
- 第一步，準備ClusterRole的資源描述，創建名為cr-deployment.yaml的文件，如圖7所示：
圖7 deployment-clusterrole資源
其中verbs用于限定可執行的操作，可配置參數有：“get”, “list”, “watch”, “create”, “update”, “patch”, “delete”, “exec”。resources用于限定可訪問的資源范圍，可配置參數有：“services”, “endpoints”, “pods”,“secrets”,“configmaps”,“crontabs”,“deployments”,“jobs”,“nodes”,“rolebindings”,“clusterroles”,“daemonsets”,“replicasets”,“statefulsets”,“horizontalpodautoscalers”,“replicationcontrollers”,“cronjobs”。apiGroups用于劃分訪問的資源組，可配置參數有：“”,“apps”, “autoscaling”, “batch”。
- 第二步，準備ServiceAccount的資源描述，創建名為sa-cicd.yaml的文件，如圖8所示：
圖8 sa-cicd資源
- 第三步，準備RoleBinding的資源描述，創建名為rb-cicd.yaml的文件，如圖9所示：
圖9 rolebinding資源
將前面兩步的clusterrole和ServiceAccount進行綁定，其中subjects指明了被授權的主體，當被授權對象是User或者Group時，可以使用類似如下片段subjects即可（Group的話只需要將kind的值改為Group）:
- kind: User
name: "test-user"
apiGroup: rbac.authorization.k8s.io- 第四步，使用kubectl -f 分別應用上述資源，完成主體（subject）、角色的創建與綁定。
當K8s的進程資源需要使用上述身份憑證進行權限劃分時，只需要在資源聲明文件中進行配置即可，如圖9所示：
圖10 pod資源使用ServiceAccount
為特定應用的Service Account賦權進行權限管控也是最安全的最值得推薦的。
APIServer默認的ClusterRole和ClusterRoleBinding對象，其中很多是以"system:"為前綴的，對這些對象的改動可能造成集群故障。例如Node鑒權模塊提到的system:node，這個ClusterRole為kubelet定義了權限，如果這個集群角色被改動了，kubelet就會停止工作。
所有默認的ClusterRole和RoleBinding都會用標簽kubernetes.io/bootstrapping: rbac-defaults進行標記。
Webhook鑒權
啟用Webhook模式的方式與ABAC模式相似，我們需要在apiserver啟動時指定--authorization-mode=ABAC以及一個HTTP配置文件用以指定策略嗎，可以通過參數--authorization-webhook-config-file=<策略文件路徑>，策略文件配置使用的是kubeconfig文件的格式。users部分表示APIServer的webhook，cluster代表著遠程服務。圖11部分是K8s官網給出的一個示例。
圖11 Webhook的策略配置示例
當進行認證時，API服務器會生成一個JSON對象來描述這個動作，對于一個資源類型的請求，其內容主要包含了需要被訪問的資源或請求特征，如圖12所示：
圖12 資源類型的Webhook鑒權請求示例
從圖12中我們可以看到，這個請求是User名為jane，Group為group1、gourp2為主體，請求的資源為命名空間為kittensandpoines下的pods資源，資源所屬group為unicorn.example.org，請求的執行操作為get這個資源信息。若我們的Webhook服務URL同意了這個請求，則可以返回如圖13格式的響應體。
圖13 Webhook請求同意響應示例
從圖13中我們可以看出,我們只需要填充SubjectAccessReview的status對象信息的值即可。若要拒絕請求，則可以返回圖14或圖15的響應。
圖14 Webhook請求拒絕響應示例1
圖15 Webhook請求拒絕響應示例2
圖14和圖15都是對請求進行拒絕，都給出了拒絕通過的原因，差別在于圖14的拒絕響應中增加了denied:true的信息，其表示當我們配置多了多個鑒權模塊的時候，當這個響應返回時立即拒絕請求。（默認當存在多個鑒權模塊，Webhook拒絕后可以再通過其他模塊進行鑒權，只有當其他模塊也不通過或者不存在時，才禁止訪問）
對于非資源的路徑訪問，生成的JSON請求示例如圖16所示：
圖16 非資源的路徑請求的Webhook鑒權請求示例
總結
鑒權主要是解決“誰可以對什么資源進行哪些操作”的問題。K8s的鑒權模塊主要有4個，發生在鑒權認證階段的第二階段。Node模塊主要針對kubelet需要訪問APIServer的場景；ABAC主要針對User和Group的常規用戶，控制力度較粗；RBAC即可以用于常規用戶也可以針對ServiceAccount進行管控，且管控力度十分細膩，是常用的K8s鑒權方式；Webhook主要用于定制自定義的鑒權邏輯，可用于跨云的集中式鑒權。
參考文獻：
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/node/
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/abac/
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/webhook/ https://www.cnblogs.com/maiblogs/p/16271997.html
https://cloud.tencent.com/developer/article/2149852
