Profilanwendbarkeit: Stufe 1
Aktivieren Sie die Kubelet-Authentifizierung mit Zertifikaten.
Die Verbindungen vom Apiserver zum Kubelet werden verwendet, um Protokolle für Pods
abzurufen, sich (über kubectl) mit laufenden Pods zu verbinden und die Port-Weiterleitungsfunktionalität
des Kubelets zu nutzen. Diese Verbindungen enden am HTTPS-Endpunkt des Kubelets. Standardmäßig
überprüft der Apiserver das Dienstzertifikat des Kubelets 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.
![]() |
HinweisSiehe die GKE-Dokumentation für den Standardwert.
|
Auswirkung
Sie müssen TLS sowohl auf dem Apiserver als auch auf den Kubelets konfigurieren.
Prüfung
Prüfmethode 1:
Kubelets können Konfigurationen aus einer Konfigurationsdatei und in einigen Fällen
aus Befehlszeilenargumenten akzeptieren. Es ist wichtig zu beachten, dass Parameter,
die als Befehlszeilenargumente bereitgestellt werden, ihre entsprechenden Parameter
in der Konfigurationsdatei überschreiben (siehe
--config
Details in der Kubelet CLI-Referenz für Weitere Informationen, wo Sie auch herausfinden können, welche Konfigurationsparameter
als Befehlszeilenargument bereitgestellt werden können). Vor diesem Hintergrund ist
es wichtig, sowohl das Vorhandensein von Befehlszeilenargumenten als auch von Einträgen
in der Konfigurationsdatei zu überprüfen, wenn die Kubelet-Konfiguration geprüft wird.- SSH zu jedem Knoten und führen Sie den folgenden Befehl aus, um den Kubelet-Prozess
zu finden:
ps -ef | grep kubelet
Die Ausgabe des obigen Befehls liefert Details des aktiven Kubelet-Prozesses, aus denen wir die dem Prozess bereitgestellten Befehlszeilenargumente sehen können. Beachten Sie auch den Speicherort der Konfigurationsdatei, die mit dem Argument--config
bereitgestellt wird, da diese zur Überprüfung der Konfiguration benötigt wird. - Die Datei kann mit einem Befehl wie
more
oderless
angezeigt werden:sudo less /path/to/kubelet-config.json
- Überprüfen Sie, ob eine Client-Zertifikat-Autoritätsdatei konfiguriert ist. Dies kann
über ein Befehlszeilenargument für den Kubelet-Dienst mit
--client-ca-file
oder in der Kubelet-Konfigurationsdatei über"authentication": { "x509": {"clientCAFile": <path/to/client-ca-file> } }"
konfiguriert werden.
Prüfmethode 2:
Es ist auch möglich, die laufende Konfiguration eines Kubelet über den /configz-Endpunkt
der Kubernetes-API zu überprüfen. Verwenden Sie
kubectl
, um Ihre Anfragen an die API zu proxyen.- Entdecken Sie alle Knoten in Ihrem Cluster, indem Sie den folgenden Befehl ausführen:
kubectl get nodes
- Initiieren Sie einen Proxy mit
kubectl
auf einem lokalen Port Ihrer Wahl, zum Beispiel:kubectl proxy --port=8080
- Während dies läuft, führen Sie in einem separaten Terminal den folgenden Befehl für
jeden Knoten aus:
export NODE_NAME=my-node-name curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz
Der Curl-Befehl gibt die API-Antwort zurück, die eine JSON-formatierte Zeichenkette darstellt, die die Kubelet-Konfiguration repräsentiert. - Überprüfen Sie, ob eine Client-Zertifikatsbehörde-Datei mit
"authentication": { "x509": {"clientCAFile": <path/to/client-ca-file> } }"
in der API-Antwort konfiguriert ist.
Wiederherstellung
Behebungsmethode 1:
Wenn Sie die Konfiguration über die Kubelet-Konfigurationsdatei vornehmen, lokalisieren
Sie zuerst die Datei:
- SSH zu jedem Knoten und führen Sie den folgenden Befehl aus, um den Kubelet-Prozess
zu finden:
ps -ef | grep kubelet
Die Ausgabe des obigen Befehls liefert Details des aktiven Kubelet-Prozesses, aus denen wir den Speicherort der Konfigurationsdatei sehen können, die dem Kubelet-Dienst mit dem--config
-Argument bereitgestellt wird. - Die Datei kann mit einem Befehl wie
more
oderless
angezeigt werden:sudo less /path/to/kubelet-config.json
- Konfigurieren Sie die Client-Zertifikatsbehörde-Datei, indem Sie den folgenden Parameter
entsprechend festlegen:
"authentication": { "x509": {"clientCAFile": <path/to/client-ca-file> } }"
Sanierungsmethode 2:
- Wenn ausführbare Argumente verwendet werden, bearbeiten Sie die Kubelet-Dienstdatei
auf jedem Worker-Knoten und stellen Sie sicher, dass die untenstehenden Parameter
Teil der
KUBELET_ARGS
-Variablenzeichenfolge sind. - Für Systeme, die
systemd
verwenden, wie die Amazon EKS Optimized Amazon Linux oder Bottlerocket AMIs, kann diese Datei unter/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
gefunden werden. - Andernfalls müssen Sie möglicherweise die Dokumentation für Ihr gewähltes Betriebssystem
nachschlagen, um festzustellen, welcher Dienstmanager konfiguriert ist:
--client-ca-file=<path/to/client-ca-file>
.
Für beide Abhilfemaßnahmen:
Basierend auf Ihrem System starten Sie den
kubelet
-Dienst neu und überprüfen Sie den Dienststatus. Das folgende Beispiel gilt für Betriebssysteme,
die systemd
verwenden, wie die Amazon EKS Optimised Amazon Linux oder Bottlerocket AMIs, und
ruft den systemctl
-Befehl auf. Wenn systemctl
nicht verfügbar ist, müssen Sie die Dokumentation für Ihr gewähltes Betriebssystem
konsultieren, um festzustellen, welcher Dienstmanager konfiguriert ist:
systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l