3.2.2 - 確保 --authorization-mode 參數未設定為 AlwaysAllow（自動化）

檢視次數:

設定檔適用性：等級 1

請勿允許所有請求。啟用明確授權。

Kubelets 可以配置為允許所有已驗證的請求（甚至是匿名請求），而不需要 apiserver 的明確授權檢查。您應該限制此行為，僅允許明確授權的請求。

注意

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

影響

未授權的請求將被拒絕。

稽核

稽核方法 1：

Kubelet 可以透過配置檔案接受配置，在某些情況下也可以透過命令列參數接受配置。需要注意的是，作為命令列參數提供的參數將會覆蓋配置檔案中的對應參數（有關 --config 的詳細資訊，請參閱 Kubelet CLI 參考資料，在那裡您也可以找到哪些配置參數可以作為命令列參數提供）。

考慮到這一點，在審核 Kubelet 配置時，檢查命令行參數和配置文件條目是否存在是很重要的。

SSH到每個節點並執行以下命令以查找Kubelet進程：
```
ps -ef | grep kubelet
```
上述命令的輸出提供了活躍的 Kubelet 進程的詳細資訊，從中我們可以看到提供給進程的命令行參數。還請注意配置檔案的位置資訊，這是通過 --config 參數提供的，因為這將需要用來驗證配置。
可以使用類似 more 或 less 的命令來查看檔案，如下所示：
```
sudo less /path/to/kubelet-config.json
```
確認 Webhook 驗證已啟動。這可以作為命令行參數啟動 kubelet 服務，使用 --authentication-token-webhook，或在 kubelet 配置文件中通過 "authentication": { "webhook": { "enabled": true } } 啟動。
驗證授權模式是否設置為 WebHook。這可以作為命令行參數通過 --authorization-mode=Webhook 設置到 kubelet 服務，或者在配置文件中通過 "authorization": { "mode": "Webhook" } 設置。

稽核方法 2：

也可以透過 Kubernetes API 的 /configz 端點查看 Kubelet 的運行配置。這可以使用 kubectl 來 Proxy 您的請求到 API。

透過執行以下指令來發現您叢集中的所有節點：
```
kubectl get nodes
```
使用 kubectl 在您選擇的本地端口上啟動 Proxy。在此範例中，我們將使用 8080：
```
kubectl proxy --port=8080
```
在執行此操作的同時，請在另一個終端機中為每個節點執行以下命令：
```
export NODE_NAME=my-node-name
curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz
```
curl 命令將返回 API 回應，這將是一個 JSON 格式的字串，代表 Kubelet 配置。
確認在 API 回應中，Webhook 驗證已啟動，格式為 "authentication": { "webhook": { "enabled": true } }。
確認授權模式在 API 回應中設定為 WebHook，使用 "authorization": { "mode": "Webhook" }。

補救

修復方法 1：

如果通過 Kubelet 配置檔進行配置，請 SSH 到每個節點並執行以下命令以查找 kubelet 進程：
```
ps -ef | grep kubelet
```
輸出提供了活動中的 kubelet 進程的詳細資訊，從中我們可以看到通過 --config 參數提供給 kubelet 服務的配置檔案的位置資訊。
可以使用類似 more 或 less 的命令來查看檔案，如下所示：
```
sudo less /path/to/kubelet-config.json
```

透過設定以下參數啟用 Webhook 驗證：

"authentication": { "webhook": { "enabled": true } }

接下來，透過設定以下參數將授權模式設為 Webhook：
```
"authorization": { "mode": "Webhook" }
```
驗證和授權欄位的詳細資訊可以在Kubelet 設定文件中找到。

修復方法 2：

如果使用可執行參數，請編輯每個工作節點上的 kubelet 服務檔案，並確保以下參數是 KUBELET_ARGS 變數字串的一部分。

對於使用systemd的系統，例如 Amazon EKS 優化的 Amazon Linux 或 Bottlerocket AMIs，該檔案可以在/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf找到。否則，您可能需要查閱您選擇的作業系統的文件，以確定配置了哪個服務管理器：

--authentication-token-webhook
--authorization-mode=Webhook

針對兩種修復步驟：

根據您的系統，重新啟動kubelet服務並檢查服務狀態。以下範例適用於使用systemd的作業系統，例如 Amazon EKS 優化的 Amazon Linux 或 Bottlerocket AMI，並調用systemctl命令。如果systemctl不可用，則您需要查閱所選作業系統的文檔以確定配置了哪個服務管理器：

systemctl daemon-reload
systemctl restart kubelet.service
systemctl status kubelet -l