設定檔適用性：等級 1
關閉對 Kubelet 伺服器的匿名請求。
當已啟動時，未被其他配置的驗證方法拒絕的請求將被視為匿名請求。這些請求隨後由 Kubelet 伺服器處理。您應依賴驗證來授權訪問並禁止匿名請求。
 |
注意請參閱 GKE 文件以了解預設值。
|
影響
匿名請求將被拒絕。
稽核
稽核方法 1：
Kubelet 可以接受來自配置檔案的配置，有時也可以接受命令行參數。需要注意的是，作為命令行參數提供的參數將覆蓋配置檔案中的對應參數（請參閱 Kubelet CLI 參考 中的
--config 詳細資訊，您也可以在那裡找到哪些配置參數可以作為命令行參數提供）。考慮到這一點，在審核 Kubelet 配置時，檢查命令行參數和配置檔案條目的存在是很重要的。- SSH到每個節點並執行以下命令以查找Kubelet進程：
ps -ef | grep kubelet
上述命令的輸出提供了活躍的 Kubelet 進程的詳細資訊，從中我們可以看到提供給進程的命令行參數。另請注意配置檔案的位置資訊，該檔案是通過--config參數提供的，因為這將需要用來驗證配置。 - 可以使用
more或less等命令查看檔案：sudo less /path/to/kubelet-config.json
- 確認未啟動匿名驗證。這可以通過命令行參數
--anonymous-auth=false配置到kubelet服務中，或者在kubelet配置文件中使用"authentication": { "anonymous": { "enabled": false }進行配置。
稽核方法 2：
您也可以透過 Kubernetes API 的 /configz 端點查看 Kubelet 的運行配置。使用
kubectl 來 Proxy 您的請求到 API。- 透過執行以下指令來發現您叢集中的所有節點：
kubectl get nodes
- 使用
kubectl在您選擇的本地端口上啟動 Proxy，例如：kubectl proxy --port=8080
- 在執行此操作時，請在另一個終端機中為每個節點執行以下命令：
export NODE_NAME=my-node-name curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configzcurl 命令將返回 API 回應，這將是一個 JSON 格式的字串，代表 Kubelet 配置。 - 確認匿名驗證未啟動，檢查 API 回應中是否包含
"authentication": { "anonymous": { "enabled": false }。
補救
修復方法 1：
如果透過 Kubelet 配置檔案進行配置，首先找到該檔案：
- SSH 到每個節點並執行以下命令以查找 kubelet 進程：
ps -ef | grep kubelet
上述命令的輸出提供了活躍的 kubelet 進程的詳細資訊，從中我們可以看到使用--config參數提供給 kubelet 服務的配置檔案位置資訊。 - 可以使用
more或less等命令查看檔案：sudo less /path/to/kubelet-config.json
- 透過設定以下參數來關閉匿名驗證：
"authentication": { "anonymous": { "enabled": false } }
修復方法 2：
- 如果使用可執行參數，請編輯每個工作節點上的 kubelet 服務檔案，並確保以下參數是
KUBELET_ARGS變數字串的一部分。 - 對於使用
systemd的系統，例如 Amazon EKS 優化的 Amazon Linux 或 Bottlerocket AMI，該檔案可以在/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf中找到。 - 否則，您可能需要查閱您選擇的作業系統的文件，以確定配置了哪個服務管理器：
--anonymous-auth=false。
對於兩個修復步驟：
根據您的系統，重新啟動
kubelet服務並檢查服務狀態。以下範例適用於使用systemd的作業系統，例如 Amazon EKS 優化的 Amazon Linux 或 Bottlerocket AMIs，並調用systemctl命令。如果systemctl不可用，則您需要查閱您選擇的作業系統的文檔以確定配置了哪個服務管理器：
systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l