如何在容器服務(wù)TKE中使用動態(tài)準入控制器

發(fā)布時間：2021-12-24 10:09:55 來源：億速云閱讀：107 作者：柒染欄目：云計算

如何在容器服務(wù)TKE中使用動態(tài)準入控制器，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

原理概述

動態(tài)準入控制器 Webhook 在訪問鑒權(quán)過程中可以更改請求對象或完全拒絕該請求，其調(diào)用 Webhook 服務(wù)的方式使其獨立于集群組件，具有非常大的靈活性，可以方便的做很多自定義準入控制，下圖為動態(tài)準入控制在 API 請求調(diào)用鏈的位置（來源于 Kubernetes 官網(wǎng)）：

從上圖可以看出，動態(tài)準入控制過程分為兩個階段：首先執(zhí)行 Mutating 階段，可以對到達請求進行修改，然后執(zhí)行 Validating 階段來驗證到達的請求是否被允許，兩個階段可以單獨使用也可以組合使用，本文將在 TKE 中實現(xiàn)一個簡單的動態(tài)準入控制調(diào)用示例。

查看驗證插件

在 TKE 現(xiàn)有集群版本中（1.10.5 及以上）已經(jīng)默認開啟了 validating admission webhook 和 mutating admission webhook API，如果是更低版本的集群，可以在 Apiserver Pod 中執(zhí)行 kube-apiserver -h | grep enable-admission-plugins 驗證當(dāng)前集群是否開啟，輸出插件列表中如果有 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 就說明當(dāng)前集群開啟了動態(tài)準入的控制器插件，如下圖所示：

如何在容器服務(wù)TKE中使用動態(tài)準入控制器

簽發(fā)證書

為了確保動態(tài)準入控制器調(diào)用的是可信任的 Webhook 服務(wù)端，必須通過 HTTPS 來調(diào)用 Webhook 服務(wù)（TLS認證），所以需要為 Webhook 服務(wù)端頒發(fā)證書，并且在注冊動態(tài)準入控制 Webhook 時為 caBundle 字段（ ValidatingWebhookConfiguration 和 MutatingAdmissionWebhook 資源清單中的 caBundle 字段）綁定受信任的頒發(fā)機構(gòu)證書（CA）來核驗 Webhook 服務(wù)端的證書是否可信任，這里分別介紹兩種推薦的頒發(fā)證書方法：

注意：當(dāng)ValidatingWebhookConfiguration 和 MutatingAdmissionWebhook 使用 clientConfig.service 配置時（Webhook 服務(wù)在集群內(nèi)），為服務(wù)器端頒發(fā)的證書域名必須為 <svc_name>.<svc_namespace>.svc。

方法一：制作自簽證書

制作自簽證書的方法比較獨立，不依賴于 K8s 集群，類似于為一個網(wǎng)站做一個自簽證書，有很多工具可以制作自簽證書，本示例使用 Openssl 制作自簽證書，操作步驟如下所示：

生成密鑰位數(shù)為 2048 的 ca.key：
```
openssl genrsa -out ca.key 2048
```
依據(jù) ca.key 生成 ca.crt，"webserver.default.svc" 為 Webhook 服務(wù)端在集群中的域名，使用 -days 參數(shù)來設(shè)置證書有效時間：
```
openssl req -x509 -new -nodes -key ca.key -subj "/CN=webserver.default.svc" -days 10000 -out ca.crt
```

生成密鑰位數(shù)為 2048 的 server.key：

openssl genrsa -out server.key 2048

i. 創(chuàng)建用于生成證書簽名請求（CSR）的配置文件 csr.conf 示例如下：

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[ dn ]
C = cn
ST = shaanxi
L = xi'an
O = default
OU = websever
CN = webserver.default.svc
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth

基于配置文件 csr.conf 生成證書簽名請求：

openssl req -new -key server.key -out server.csr -config csr.conf

使用 ca.key、ca.crt 和 server.csr 頒發(fā)生成服務(wù)器證書（x509簽名）：

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 10000 \
  -extensions v3_ext -extfile csr.conf

查看 Webhook server 端證書：

openssl x509  -noout -text -in ./server.crt

其中，生成的證書、密鑰文件說明如下：

ca.crt 為頒發(fā)機構(gòu)證書，ca.key 為頒發(fā)機構(gòu)證書密鑰，用于服務(wù)端證書頒發(fā)。

server.crt 為頒發(fā)的服務(wù)端證書，server.key 為頒發(fā)的服務(wù)端證書密鑰.

方法二：使用 K8S CSR API 簽發(fā)

除了使用方案一加密工具制作自簽證書，還可以使用 k8s 的證書頒發(fā)機構(gòu)系統(tǒng)來下發(fā)證書，執(zhí)行下面腳本可使用 K8s 集群根證書和根密鑰簽發(fā)一個可信任的證書用戶，需要注意的是用戶名應(yīng)該為 Webhook 服務(wù)在集群中的域名：

USERNAME='webserver.default.svc' # 設(shè)置需要創(chuàng)建的用戶名為 Webhook 服務(wù)在集群中的域名
# 使用 Openssl 生成自簽證書 key
openssl genrsa -out ${USERNAME}.key 2048
# 使用 Openssl 生成自簽證書 CSR 文件, CN 代表用戶名，O 代表組名
openssl req -new -key ${USERNAME}.key -out ${USERNAME}.csr -subj "/CN=${USERNAME}/O=${USERNAME}" 
# 創(chuàng)建 Kubernetes 證書簽名請求（CSR）
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: ${USERNAME}
spec:
  request: $(cat ${USERNAME}.csr | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF
# 證書審批允許信任
kubectl certificate approve ${USERNAME}
# 獲取自簽證書 CRT
kubectl get csr ${USERNAME} -o jsonpath={.status.certificate} > ${USERNAME}.crt

其中， ${USERNAME}.crt 為服務(wù)端證書， ${USERNAME}.key 為 Webhook 服務(wù)端證書密鑰。

操作示例

下面將使用 ValidatingWebhookConfiguration 資源在 TKE 中實現(xiàn)一個動態(tài)準入 Webhook 調(diào)用示例，本示例代碼可在示例代碼中獲取（為了確?？稍L問性，示例代碼 Fork 自原代碼庫，作者實現(xiàn)了一個簡單的動態(tài)準入 Webhook 請求和響應(yīng)的接口，具體接口格式請參考 Webhook 請求和響應(yīng) 。為了方便，我將使用它作為我們的 Webhook 服務(wù)端代碼。

準備 caBundle 內(nèi)容

若頒發(fā)證書方法是方案一, 使用 base64 編碼 ca.crt 生成 caBundle 字段內(nèi)容：
```
 cat ca.crt | base64 --wrap=0
```
若頒發(fā)證書方法是方案二，集群的根證書即為 caBundle 字段內(nèi)容，可以通過 TKE 集群控制臺【基本信息】-> 【集群APIServer信息】Kubeconfig 內(nèi)容中的clusters.cluster[].certificate-authority-data 字段獲取，該字段已經(jīng) base64 編碼過了，無需再做處理。

復(fù)制生成的 ca.crt （頒發(fā)機構(gòu)證書），server.crt（HTTPS 證書)）, server.key（HTTPS 密鑰）到項目主目錄：
修改項目中的 Dockerfile ，添加三個證書文件到容器工作目錄：
然后使用 docker 命令構(gòu)建 Webhook 服務(wù)端鏡像：
```
docker build -t webserver .
```
部署一個域名為 "weserver.default.svc" 的 Webhook 后端服務(wù)，修改適配后的 controller.yaml 如下：
注冊創(chuàng)建類型為 ValidatingWebhookConfiguration 的資源，本示例配置的 Webhook 觸發(fā)規(guī)則是當(dāng)創(chuàng)建 pods類型，API 版本 "v1" 時觸發(fā)調(diào)用，clientConfig 配置對應(yīng)上述在集群中創(chuàng)建的的 Webhook 后端服務(wù)， caBundle 字段內(nèi)容為證書頒發(fā)方法一獲取的ca.crt 內(nèi)容，修改適配項目中的 admission.yaml 文件如下圖：
注冊好后創(chuàng)建一個 Pod 類型， API 版本為 "v1" 的測試資源如下：
測試代碼有打印請求日志，查看 Webhook 服務(wù)端日志可以看到動態(tài)準入控制器觸發(fā)了 webhook 調(diào)用，如下圖：
此時查看創(chuàng)建的測試pod 是成功創(chuàng)建的，是因為測試 Webhook 服務(wù)端代碼寫死的 allowed: true，所以是可以創(chuàng)建成功的，如下圖：
為了進一步驗證，我們把 "allowed" 改成 "false" ，然后重復(fù)上述步驟重新打 Webserver 服務(wù)端鏡像，并重新部署 controller.yaml 和 admission.yaml 資源，當(dāng)再次嘗試創(chuàng)建 "pods" 資源時請求被動態(tài)準入攔截，說明配置的動態(tài)準入策略是生效的，如下圖所示：