檢視次數:
設定檔適用性：級別 1
不允許所有請求。啟用顯式授權。
Kubelets 可以配置為允許所有已驗證的請求（即使是匿名的）而不需要 apiserver 的明確授權檢查。您應該限制此行為，僅允許明確授權的請求。
注意
注意
請參閱 GKE 文件以了解預設值。

影響

請參閱 GKE 文件以了解預設值。

稽核

稽核方法 1：
Kubelets 可以接受來自配置檔案的配置，在某些情況下也可以接受命令行參數。需要注意的是，作為命令行參數提供的參數將覆蓋配置檔案中的對應參數（請參閱 Kubelet CLI 參考 中的 --config 詳細資訊以獲取更多資訊，您也可以在此找到哪些配置參數可以作為命令行參數提供）。考慮到這一點，在審核 Kubelet 配置時，檢查命令行參數和配置檔案條目的存在非常重要。
  1. SSH到每個節點並執行以下命令以查找Kubelet進程： 
    ps -ef | grep kubelet
    上述命令的輸出提供了活躍的 Kubelet 進程的詳細資訊，從中我們可以看到提供給進程的命令行參數。另請注意配置檔案的位置資訊，該檔案是通過 --config 參數提供的，因為這將需要用來驗證配置。
  2. 可以使用類似 more 或 less 的命令查看檔案： 
    sudo less /path/to/kubelet-config.json
  3. 確認 Webhook 驗證已啟動。這可以透過命令行參數 --authentication-token-webhook 配置到 kubelet 服務中，或在 kubelet 配置文件中使用 "authentication": { "webhook": { "enabled": true } } 進行配置。
  4. 確認授權模式已設定為WebHook。這可以透過命令行參數--authorization-mode=Webhook設定到kubelet服務，或在配置文件中使用"authorization": { "mode": "Webhook }設定。
稽核方法 2：
您也可以透過 Kubernetes API 的 /configz 端點查看 Kubelet 的運行配置。使用 kubectl 來 Proxy 您的請求到 API。
  1. 透過執行以下命令來發現您叢集中的所有節點： 
    kubectl get nodes
  2. 使用 kubectl 在您選擇的本地端口上啟動 Proxy，例如： 
    kubectl proxy --port=8080
  3. 在執行此操作時，請在另一個終端機中為每個節點執行以下命令： 
    export NODE_NAME=my-node-name 
curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz
    curl 命令將返回 API 回應，這將是一個 JSON 格式的字串，代表 Kubelet 配置。
  4. 確認 API 回應中包含 "authentication": { "webhook": { "enabled": true } }，以驗證 Webhook 驗證是否已啟動。
  5. 驗證授權模式在 API 回應中設定為 WebHook，使用 "authorization": { "mode": "Webhook" }。

補救

修復方法 1：
如果透過 Kubelet 配置檔案進行配置，首先找到該檔案：
  1. SSH 到每個節點並執行以下命令以查找 kubelet 進程： 
    ps -ef | grep kubelet
    上述命令的輸出提供了活躍的 kubelet 進程的詳細資訊，從中我們可以看到使用 --config 參數提供給 kubelet 服務的配置檔案位置資訊。
  2. 可以使用類似 more 或 less 的命令查看檔案： 
    sudo less /path/to/kubelet-config.json
  3. 透過設定以下參數啟用 Webhook 驗證： 
    "authentication": { "anonymous": { "enabled": false } }
  4. 接下來，透過設定以下參數將授權模式設為 Webhook： 
    "authorization": { "mode": "Webhook }
    驗證和授權欄位的詳細資訊可以在Kubelet 配置文件中找到。
修復方法 2：
  1. 如果使用可執行參數，請編輯每個工作節點上的 kubelet 服務檔案，並確保以下參數是 KUBELET_ARGS 變數字串的一部分。
  2. 對於使用systemd的系統，例如 Amazon EKS 優化的 Amazon Linux 或 Bottlerocket AMIs，該檔案可以在/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf中找到。
  3. 否則，您可能需要查閱您選擇的作業系統的文件，以確定配置了哪個服務管理器： 
    --authentication-token-webhook
--authorization-mode=Webhook
針對兩個修復步驟：
根據您的系統，重新啟動kubelet服務並檢查服務狀態。以下範例適用於使用systemd的作業系統，例如 Amazon EKS 優化的 Amazon Linux 或 Bottlerocket AMIs，並調用systemctl命令。如果systemctl不可用，則您需要查閱您選擇的作業系統的文檔以確定配置了哪個服務管理器： 
systemctl daemon-reload 
systemctl restart kubelet.service 
systemctl status kubelet -l