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 Sicherheitsinformationen und Analysen, die sicherstellen, dass Ihre Umgebung kontinuierlich mit den Ereignisdaten überwacht wird.

Hinweis

Weitere Informationen finden Sie in der Dokumentation des AKS für den Standardwert.

Auswirkung

Das Festlegen dieses Parameters auf 0 könnte zu einem Denial-of-Service-Zustand führen, da übermäßig viele Ereignisse erstellt werden. Die Cluster-Ereignisverarbeitungs- und Speichersysteme sollten so skaliert werden, dass sie die erwarteten Ereignislasten bewältigen können.

Prüfung

Audit Method 1

SSH zu jedem Knoten.
Führen Sie den folgenden Befehl auf jedem Knoten aus, um den Kubelet-Prozess zu finden:
```
ps -ef | grep kubelet
```
Überprüfen Sie den für das Argument --eventRecordQPS festgelegten Wert und bestimmen Sie, ob dieser auf einem angemessenen Niveau für den Cluster eingestellt ist. 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

Wenn ein Eintrag für eventRecordQPS vorhanden ist, überprüfen Sie, ob er auf 0 oder ein angemessenes Niveau 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-und-Portnummer" NODE_NAME="Der-Name-des-Knotens-zur-Konfigurationsausgabe"
                     aus der Ausgabe von "kubectl get nodes"

kubectl proxy --port=8001 &

export HOSTNAME_PORT=localhost:8001
export NODE_NAME=ip-192.168.31.226.aks.internal

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 Datei kubelet-config.json /etc/kubernetes/kubelet/kubelet-config.json und setzen Sie den folgenden 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 detaillierte Schritt-für-Schritt-Anweisungen zur ConfigMap in Rekonfigurieren eines Node-Kubelets in einem Live-Cluster, und führen Sie dann die Curl-Anweisung aus dem Audit-Prozess erneut aus, um Änderungen an der Kubelet-Konfiguration zu überprüfen:

kubectl proxy --port=8001 &

export HOSTNAME_PORT=localhost:8001
export NODE_NAME=ip-192.168.31.226.aks.internal

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

For all three remediations: Basierend auf Ihrem System, starten Sie den Kubelet-Dienst neu und überprüfen Sie den Status:

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