Ansichten:
Profilanwendbarkeit: Stufe 1
Aktivieren Sie die Kubelet-Authentifizierung mit Zertifikaten.
Die Verbindungen vom Apiserver zum Kubelet werden zum Abrufen von Protokollen für Pods, zum Anhängen (über kubectl) an laufende Pods und zur Nutzung der Port-Weiterleitungsfunktionalität des Kubelet verwendet. Diese Verbindungen enden am HTTPS-Endpunkt des Kubelet. Standardmäßig überprüft der Apiserver das vom Kubelet bereitgestellte Zertifikat nicht, was die Verbindung anfällig für Man-in-the-Middle-Angriffe macht und unsicher über unzuverlässige und/oder öffentliche Netzwerke auszuführen ist. Die Aktivierung der Kubelet-Zertifikatsauthentifizierung stellt sicher, dass der Apiserver das Kubelet authentifizieren kann, bevor Anfragen gestellt werden.
Hinweis
Hinweis
Siehe die Azure AKS-Dokumentation für den Standardwert.

Auswirkung

Sie müssen TLS sowohl auf dem Apiserver als auch auf den Kubelets konfigurieren.

Prüfung

Audit Method 1
Wenn eine Kubelet-Konfigurationsdatei verwendet wird, überprüfen Sie, ob ein Eintrag für "x509": {"clientCAFile:" auf den Speicherort der Client-Zertifikatsstelle gesetzt ist.
  1. SSH zum entsprechenden Knoten.
  2. Führen Sie den folgenden Befehl auf jedem Knoten aus, um die entsprechende 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 angibt.
  3. Öffnen Sie die Kubelet-Konfigurationsdatei:
    sudo more /etc/kubernetes/kubelet/kubelet-config.json
  4. Überprüfen Sie, dass das Argument "x509": {"clientCAFile:" existiert und auf den Speicherort der Client-Zertifikatsstelle verweist.
Wenn das Argument "x509": {"clientCAFile:" nicht vorhanden ist, überprüfen Sie, ob eine Kubelet-Konfigurationsdatei durch --config angegeben ist und ob die Datei "authentication": { "x509": {"clientCAFile:" auf den Speicherort der Client-Zertifizierungsstellen-Datei setzt.
Audit Method 2
Wenn Sie den api configz Endpunkt verwenden, suchen Sie nach dem Status von authentication.. x509":("clientCAFile":"/etc/kubernetes/pki/ca.crt, indem Sie die Live-Konfiguration von den Knoten extrahieren, die Kubelet ausführen.
  1. 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:
"authentication": { "x509": {"clientCAFile:" to the location of the client CA file.
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:
--client-ca-file=<path/to/client-ca-file>
Remediation Method 3
Wenn Sie den api configz Endpunkt verwenden, suchen Sie nach dem Status von "authentication.*x509":("clientCAFile":"/etc/kubernetes/pki/ca.crt", 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