3.2.2 - Stellen Sie sicher, dass das Argument --authorization-mode nicht auf AlwaysAllow gesetzt ist (Automatisiert)

Ansichten:

Profilanwendbarkeit: Stufe 1

Nicht alle Anfragen zulassen. Explizite Autorisierung aktivieren.

Standardmäßig erlauben Kubelets alle authentifizierten Anfragen (auch anonyme), ohne dass explizite Autorisierungsprüfungen vom Apiserver erforderlich sind. Sie sollten dieses Verhalten einschränken und nur ausdrücklich autorisierte Anfragen zulassen.

Hinweis

Siehe die Azure AKS-Dokumentation für den Standardwert.

Auswirkung

Unbefugte Anfragen werden abgelehnt.

Prüfung

Audit Method 1:

Wenn eine Kubelet-Konfigurationsdatei verwendet wird, überprüfen Sie, ob ein Eintrag für "authentication": { "webhook": { "enabled": true } vorhanden ist.

SSH zum entsprechenden Knoten und führen Sie den folgenden Befehl aus, um die Kubelet-Konfigurationsdatei zu finden:
```
ps -ef | grep kubelet
```
Die Ausgabe sollte etwas Ähnliches wie --config /etc/kubernetes/kubelet/kubelet-config.json zurückgeben, was den Speicherort der Kubelet-Konfigurationsdatei darstellt.

Öffnen Sie die Kubelet-Konfigurationsdatei:

sudo more /etc/kubernetes/kubelet/kubelet-config.json

Überprüfen Sie, ob "authentication": {"webhook": {"enabled": true}} vorhanden ist und ob "authentication": {"mode": { nicht auf AlwaysAllow gesetzt ist.

Wenn das Argument "authentication": {"mode": { vorhanden ist, überprüfen Sie, dass es nicht auf AlwaysAllow gesetzt ist. Wenn es nicht vorhanden ist, überprüfen Sie, dass eine Kubelet-Konfigurationsdatei durch --config angegeben ist und dass diese Datei "authentication": {"mode": { auf etwas anderes als AlwaysAllow setzt.

Audit Method 2:

Wenn Sie den API-Configz-Endpunkt verwenden, ziehen Sie in Betracht, den Status von "authentication"... "webhook":{"enabled":true} zu suchen, indem Sie die Live-Konfiguration von den Knoten extrahieren, die Kubelet ausführen.

Legen Sie die lokale Proxy-Portnummer und die folgenden Variablen fest und geben Sie die Proxy-Portnummer und den Knotennamen an:
- HOSTNAME_PORT="localhost-and-port-number"
- NODE_NAME="The-Name-Of-Node-To-Extract-Configuration" (from the output of "kubectl get nodes")
```
kubectl proxy --port=8001 &

export HOSTNAME_PORT=localhost:8001 (example host and port number)
export NODE_NAME=ip-192.168.31.226.aks.internal (example node name from
"kubectl get nodes")

curl -sSL "http://${HOSTNAME_PORT}/api/v1/nodes/${NODE_NAME}/proxy/configz"
      
```

Wiederherstellung

Remediation Method 1:

Wenn Sie die Kubelet-Konfigurationsdatei ändern, bearbeiten Sie die kubelet-config.json-Datei /etc/kubernetes/kubelet/kubelet-config.json und stellen Sie sicher, dass der Parameter korrekt eingestellt ist:

"authentication"... "webhook":{"enabled":true

Remediation Method 2:

Wenn ausführbare Argumente verwendet werden, bearbeiten Sie die Kubelet-Dienstdatei /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf auf jedem Worker-Knoten und fügen Sie Folgendes zur KUBELET_ARGS-Variablenzeichenfolge hinzu:

--authorization-mode=Webhook

Remediation Method 3:

Wenn Sie den API-Configz-Endpunkt verwenden, überprüfen Sie, dass "authentication.*webhook":{"enabled":true} vorhanden ist, indem Sie die Live-Konfiguration von den Knoten extrahieren, die Kubelet ausführen.

Finden Sie schrittweise ConfigMap-Verfahren in der Kubernetes-Dokumentation. Konfigurieren Sie den Kubelet eines Knotens in einem Live-Cluster neu und führen Sie die curl-Anweisung aus dem Audit-Prozess erneut aus, um die Konfigurationsänderungen zu überprüfen:

"kubectl proxy --port=8001 &"

"export HOSTNAME_PORT=localhost:8001 (example host and port number) 
export NODE_NAME=ip-192.168.31.226.aks.internal (example node name from 
""kubectl get nodes"")"

"curl -sSL ""http://${HOSTNAME_PORT}/api/v1/nodes/${NODE_NAME}/proxy/configz"""

For all three remediations:

Starten Sie den kubelet-Dienst neu und überprüfen Sie den Status:

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