您好,登錄后才能下訂單哦!
如何在容器服務TKE中使用動態準入控制器,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
動態準入控制器 Webhook 在訪問鑒權過程中可以更改請求對象或完全拒絕該請求,其調用 Webhook 服務的方式使其獨立于集群組件,具有非常大的靈活性,可以方便的做很多自定義準入控制,下圖為動態準入控制在 API 請求調用鏈的位置(來源于 Kubernetes 官網):
從上圖可以看出,動態準入控制過程分為兩個階段:首先執行 Mutating 階段,可以對到達請求進行修改,然后執行 Validating 階段來驗證到達的請求是否被允許,兩個階段可以單獨使用也可以組合使用,本文將在 TKE 中實現一個簡單的動態準入控制調用示例。
在 TKE 現有集群版本中(1.10.5 及以上)已經默認開啟了 validating admission webhook 和 mutating admission webhook API,如果是更低版本的集群,可以在 Apiserver Pod 中執行 kube-apiserver -h | grep enable-admission-plugins
驗證當前集群是否開啟,輸出插件列表中如果有 MutatingAdmissionWebhook
和 ValidatingAdmissionWebhook
就說明當前集群開啟了動態準入的控制器插件,如下圖所示:
為了確保動態準入控制器調用的是可信任的 Webhook 服務端,必須通過 HTTPS 來調用 Webhook 服務(TLS認證), 所以需要為 Webhook 服務端頒發證書,并且在注冊動態準入控制 Webhook 時為 caBundle
字段( ValidatingWebhookConfiguration
和 MutatingAdmissionWebhook
資源清單中的 caBundle
字段)綁定受信任的頒發機構證書(CA)來核驗 Webhook 服務端的證書是否可信任, 這里分別介紹兩種推薦的頒發證書方法:
注意:當
ValidatingWebhookConfiguration
和MutatingAdmissionWebhook
使用clientConfig.service
配置時(Webhook 服務在集群內),為服務器端頒發的證書域名必須為<svc_name>.<svc_namespace>.svc
。
制作自簽證書的方法比較獨立,不依賴于 K8s 集群,類似于為一個網站做一個自簽證書,有很多工具可以制作自簽證書,本示例使用 Openssl 制作自簽證書,操作步驟如下所示:
生成密鑰位數為 2048 的 ca.key:
openssl genrsa -out ca.key 2048
依據 ca.key 生成 ca.crt,"webserver.default.svc" 為 Webhook 服務端在集群中的域名,使用 -days
參數來設置證書有效時間:
openssl req -x509 -new -nodes -key ca.key -subj "/CN=webserver.default.svc" -days 10000 -out ca.crt
生成密鑰位數為 2048 的 server.key:
openssl genrsa -out server.key 2048
i. 創建用于生成證書簽名請求(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 頒發生成服務器證書(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 為頒發機構證書,ca.key 為頒發機構證書密鑰,用于服務端證書頒發。
server.crt 為 頒發的服務端證書,server.key 為頒發的服務端證書密鑰.
除了使用方案一加密工具制作自簽證書,還可以使用 k8s 的證書頒發機構系統來下發證書,執行下面腳本可使用 K8s 集群根證書和根密鑰簽發一個可信任的證書用戶,需要注意的是用戶名應該為 Webhook 服務在集群中的域名:
USERNAME='webserver.default.svc' # 設置需要創建的用戶名為 Webhook 服務在集群中的域名 # 使用 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}" # 創建 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 為服務端證書, ${USERNAME}
.key 為 Webhook 服務端證書密鑰。
下面將使用 ValidatingWebhookConfiguration
資源在 TKE 中實現一個動態準入 Webhook 調用示例,本示例代碼可在 示例代碼 中獲取(為了確保可訪問性,示例代碼 Fork 自 原代碼庫,作者實現了一個簡單的動態準入 Webhook 請求和響應的接口,具體接口格式請參考 Webhook 請求和響應 。為了方便,我將使用它作為我們的 Webhook 服務端代碼。
準備 caBundle
內容
若頒發證書方法是方案一, 使用 base64
編碼 ca.crt 生成 caBundle
字段內容:
cat ca.crt | base64 --wrap=0
若頒發證書方法是方案二,集群的根證書即為 caBundle
字段內容,可以通過 TKE 集群控制臺【基本信息】-> 【集群APIServer信息】Kubeconfig 內容中的clusters.cluster[].certificate-authority-data
字段獲取,該字段已經 base64
編碼過了,無需再做處理。
復制生成的 ca.crt (頒發機構證書),server.crt(HTTPS 證書)), server.key(HTTPS 密鑰) 到項目主目錄:
修改項目中的 Dockerfile ,添加三個證書文件到容器工作目錄:
然后使用 docker 命令構建 Webhook 服務端鏡像:
docker build -t webserver .
部署一個域名為 "weserver.default.svc" 的 Webhook 后端服務,修改適配后的 controller.yaml 如下:
注冊創建類型為 ValidatingWebhookConfiguration
的資源,本示例配置的 Webhook 觸發規則是當創建 pods
類型,API 版本 "v1" 時觸發調用,clientConfig
配置對應上述在集群中創建的的 Webhook 后端服務, caBundle
字段內容為證書頒發方法一獲取的ca.crt 內容,修改適配項目中的 admission.yaml 文件如下圖:
注冊好后創建一個 Pod 類型, API 版本為 "v1" 的測試資源如下:
測試代碼有打印請求日志, 查看 Webhook 服務端日志可以看到動態準入控制器觸發了 webhook 調用,如下圖:
此時查看創建的測試pod 是成功創建的,是因為測試 Webhook 服務端代碼寫死的 allowed: true
,所以是可以創建成功的,如下圖:
為了進一步驗證,我們把 "allowed" 改成 "false" ,然后重復上述步驟重新打 Webserver 服務端鏡像,并重新部署 controller.yaml 和 admission.yaml 資源,當再次嘗試創建 "pods" 資源時請求被動態準入攔截,說明配置的動態準入策略是生效的,如下圖所示:
關于如何在容器服務TKE中使用動態準入控制器問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。