3.2.7 - Stellen Sie sicher, dass das Argument --eventRecordQPS auf 0 oder ein Niveau eingestellt ist, das eine angemessene Ereigniserfassung gewährleistet (Automatisiert)

Ansichten:

Profilanwendbarkeit: Stufe 2

Sicherheitsrelevante Informationen sollten erfasst werden. Das --eventRecordQPS-Flag auf dem Kubelet kann verwendet werden, um die Rate zu begrenzen, mit der Ereignisse erfasst werden. Eine zu niedrige Einstellung könnte dazu führen, dass relevante Ereignisse nicht protokolliert werden, während die unbegrenzte Einstellung von 0 zu einem Denial-of-Service auf dem Kubelet führen könnte.

Es ist wichtig, alle Ereignisse zu erfassen und die Erstellung von Ereignissen nicht einzuschränken. Ereignisse sind eine wichtige Quelle für Sicherheitsinfo und Analysen, die sicherstellen, dass Ihre Umgebung kontinuierlich mit den Ereignisdaten überwacht wird.

Hinweis

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

Prüfung

Audit Method 1:

SSH zum entsprechenden Knoten und führen Sie den folgenden Befehl auf jedem Knoten aus, um den Kubelet-Prozess zu finden:
```
ps -ef | grep kubelet
```
Überprüfen Sie im Ausgabeergebnis des obigen Befehls den für das Argument --eventRecordQPS festgelegten Wert und bestimmen Sie, ob dieser auf ein angemessenes Niveau für den Cluster eingestellt wurde. Der Wert 0 kann verwendet werden, um sicherzustellen, dass alle Ereignisse erfasst werden.
Falls das Argument --eventRecordQPS nicht existiert, überprüfen Sie, ob eine Kubelet-Konfigurationsdatei durch --config angegeben ist, und überprüfen Sie den Wert an diesem Ort.

Die Ausgabe des obigen Befehls 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:

cat /etc/kubernetes/kubelet/kubelet-config.json

Überprüfen Sie, ob "eventRecordQPS" auf 0 oder eine andere geeignete Stufe für den Cluster eingestellt ist.

Audit Method 2:

Wenn Sie den API-Configz-Endpunkt verwenden, suchen Sie nach dem Status von eventRecordQPS, 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 /etc/kubernetes/kubelet/kubelet-config.json und setzen Sie den untenstehenden Parameter auf 5 oder einen Wert größer oder gleich 0:

"eventRecordQPS": 5

Überprüfen Sie, dass /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf kein ausführbares Argument für eventRecordQPS definiert, da dies Ihre Kubelet-Konfiguration überschreiben würde.

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 am Ende der KUBELET_ARGS-Variablenzeichenfolge den folgenden Parameter hinzu:

--eventRecordQPS=5

Remediation Method 3:

Wenn Sie den API-Configz-Endpunkt verwenden, suchen Sie nach dem Status von "eventRecordQPS", indem Sie die Live-Konfiguration von den Knoten extrahieren, die Kubelet ausführen.

Siehe schrittweise ConfigMap-Verfahren in der Kubernetes-Dokumentation und führen Sie den Curl-Befehl aus dem Audit-Prozess erneut aus, um Änderungen an der Kubelet-Konfiguration 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