1.Kubernetes 的鑒權管理

客戶端請求通過認證階段后，將進入鑒權階段。這個階段將包含兩個內容：

• 1?? 審查客戶端請求的屬性
• 2?? 確定請求的操作

1.1 審查客戶端請求的屬性

Kubernetes 審查客戶端請求的屬性 主要包括以下幾個方面。

• 用戶與組：經過認證的用戶名和所屬組名的列表。
• API 和動作：對 Kubernetes 資源的操作，如 create、list、get 等請求動詞。
• 請求路徑和動作：指示各種非 Kubernetes 資源的路徑（如 /api），以及對該路徑執(zhí)行的 HTTP 操作（如 GET、POST、PUT 等）。
• 命名空間：正在訪問的 Kubernetes 對象的命名空間。

1.2 確定請求的操作

確定請求的操作 是指，確定對 Kubernetes 資源對象的請求動詞或 HTTP 操作，以及該動詞或 HTTP 操作是針對單個資源還是一組資源。

下表列舉常見的請求動詞與 HTTP 操作，以及它們的對應關系。

請求動詞	HTTP 操作
create	POST
get、list	GET、HEAD
update	PUT
patch	PATCH
delete、deletecollection	DELETE

根據 Kubernetes 鑒權時使用的模塊，可以將 Kubernetes 的鑒權分為以下 $4$ 種方式：

• 基于 角色 的訪問控制（RBAC 鑒權）
• 基于 屬性 的訪問控制（ABAC 鑒權）
• 基于 節(jié)點 的訪問控制（Node 鑒權）
• 基于 Webhook 的訪問控制

? 基于角色的訪問控制（RBAC 鑒權）是最重要的鑒權方式。

2.基于角色的訪問控制（RBAC 鑒權）

基于角色的訪問控制（Role-Based Access Control，RBAC），通過為用戶賦予不同的角色來控制其訪問 Kubernetes 集群資源。它允許用戶動態(tài)配置不同的角色策略?；诮巧脑L問控制需要使用 rbac.authorization.k8s.io API 組來執(zhí)行。

2.1 基于角色的訪問控制中的概念

在基于角色的訪問控制中涉及 $3$ 個非常重要的概念：角色、角色綁定 和 主體。

2.1.1 角色

角色 是一組權限的集合。Kubernetes 中的角色分為兩種：Role 和 ClusterRole。

• Role 是某個命名空間中對象訪問權限的集合。因此，在創(chuàng)建 Role 時，必須指定 Role 所屬的命名空間。
• ClusterRole 是訪問某個命名空間的權限的集合。

2.1.2 角色綁定

將包含各種權限的角色授予給一個主體，這個過程被叫作 角色綁定。因為角色分為 Role 和 ClusterRole，所以角色綁定分為 RoleBinding 和 ClusterRoleBinding。

2.1.3 主體

使用角色的用戶被叫作 主體（Subject）。它可以是一個用戶（User）、一個用戶組（Group），也可以是一個服務賬號（ServiceAccount）。

角色與角色綁定存在 $3$ 種關系：RoleBind-Role、ClusterRoleBind-ClusterRole 和 RoleBind-ClusterRole，如下圖所示。

下面解釋了這 $3$ 種關系的區(qū)別：

• User A 通過 RoleBinding 綁定到了 Role 上。因此，它就擁有了命名空間 A 的操作權限。
• 在集群 B 上有兩個命名空間：命名空間 A 和命名空間 B。User B 通過 ClusterRolebinding 綁定到 ClusterRole 上，因此它擁有了集群的操作權限（即訪問命名空間 A 和命名空間 B）。
• User C 在使用 RoleBind 和 ClusterRole 進行綁定時，僅能獲取當前名稱空間的所有權限（即 User C 只能訪問命名空間 A）。

角色、角色綁定 和 主體 之間的約束關系如下圖所示。

2.2 實現(xiàn)基于角色的訪問控制

下面來演示如何實現(xiàn)基于角色的訪問控制。這里將實現(xiàn) Jerry 用戶只能對 mydemo 命名空間擁有讀取 Pod 的權限。

創(chuàng)建 mydemo 命名空間，并在該命名空間中創(chuàng)建 Pod。

kubectl create ns mydemo
kubectl create deployment nginx --image=nginx --replicas=3 -n mydemo

查看 mydemo 命名空間中的 Pod 信息。

kubectl get pods -n mydemo

輸出的信息如下：

生成 只有讀取 Pod 權限的角色 的描述信息。

kubectl create role mydemo-pod-reader-role --verb=get,list,watch --resource=pods --dry-run -o yaml

在生成的描述信息中增加 namespace: mydemo 字段，并將描述信息保存為 mydemo-pod-reader-role.yaml 文件。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:creationTimestamp: nullname: mydemo-pod-reader-rolenamespace: mydemo
rules:
- apiGroups:- ""resources:- podsverbs:- get- list- watch

創(chuàng)建 mydemo-pod-reader-role 角色。

kubectl apply -f mydemo-pod-reader-role.yaml

查看 mydemo 命名空間中的角色信息。

kubectl get role -n mydemo

輸出的信息如下：

編輯 mydemo-pod-reader-rolebinding.yaml 文件進行角色綁定，將主體與角色進行綁定。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: mydemo-pod-reader-rolebindingnamespace: mydemo
subjects:
- kind: User#名字大小寫敏感name: JerryapiGroup: rbac.authorization.k8s.io
roleRef:kind: Role #this must be Role or ClusterRole# 名字必須與Role或者ClusterRole的名字一致name: mydemo-pod-reader-role apiGroup: rbac.authorization.k8s.io

🚀 這里的主體是用戶名稱（即 Jerry），綁定的角色是 mydemo-pod-reader-role。

執(zhí)行 kubectl apply -f 命令。

kubectl apply -f mydemo-pod-reader-rolebinding.yaml

查看 mydemo 命名空間中的角色信息與角色綁定信息。

kubectl get role,rolebinding -n mydemo

輸出的信息如下：

創(chuàng)建 Jerry 用戶和認證證書。

# 生成用戶的私鑰
openssl genrsa -out Jerry.key 2048# 使用剛生成的私鑰創(chuàng)建證書，并在 -subj 中指定用戶和組。證書文件格式: 用戶名.csr
openssl req -new -key Jerry.key -out Jerry.csr -subj "/CN=Jerry/O=mydemo"# 在 /etc/kubernetes/pki 目錄下，找到 Kubernetes 集群的證書 ca.crt 和 ca.key
# 生成最終的證書 Jerry.crt，有效期為 30 天
openssl x509 -req -in Jerry.csr -CA /etc/kubernetes/pki/ca.crt \
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial \
-out Jerry.crt -days 30

把 Jerry 用戶的憑證加入 kubeconfig。

kubectl config set-credentials Jerry --client-key=Jerry.key --client-certificate=Jerry.crt

查看 config 文件，看是否把密鑰的內容寫進去了，以便在命令行中切換用戶。

tail ~/.kube/config

輸出的信息如下：

創(chuàng)建用戶上下文對象 Jerry-contex。

kubectl config set-context Jerry-context --cluster=kubernetes --namespace=mydemo --user=Jerry

切換到 Jerry 用戶。

kubectl config use-context Jerry-context

輸出的信息如下：

🚀 在 Kubernetes 中進行用戶切換的常用命令有：

• 回到管理員：kubectl config use-context kubernetes-admin@kubernetes
• 獲取所有用戶的 context 列表：kubectl config get-contexts
• 獲取當前用戶的 context 信息：kubectl config current-context

測試 Jerry 用戶能否讀取 mydemo 命名空間中的 Pod 信息。

kubectl get pod -n mydemo

如果能夠正常讀取 mydemo 命名空間中的 Pod 信息，則輸出如下信息：

執(zhí)行以下命令測試 Jerry 用戶能否在 mydemo 命名空間中創(chuàng)建 Pod：

kubectl create deployment Jerry-nginx --image=nginx --replicas=3 -n mydemo

這時將出現(xiàn)以下錯誤信息：

error: failed to create deployment: 
deployments.apps is forbidden: 
User "Jerry" cannot create resource "deployments" in API group "apps" in the namespace "mydemo"

按照相同的方法創(chuàng)建 Tom 用戶和認證證書，并切換到 Tom 用戶，測試 Tom 用戶能否讀取 mydemo 命名空間中的 Pod 信息。