Profilanwendbarkeit: Stufe 1 - Worker-Knoten
Stellen Sie sicher, dass eine Client-CA-Datei für die Kubelet-Authentifizierung mit
Zertifikaten konfiguriert ist, um die Sicherheit zu erhöhen. Diese Konfiguration ist
entscheidend, da die Verbindungen vom Apiserver zum Kubelet, die für Aktivitäten wie
das Abrufen von Protokollen für Pods, das Anhängen an laufende Pods über kubectl und
das Aktivieren der Port-Weiterleitungsfunktion des Kubelets verwendet werden, am HTTPS-Endpunkt
des Kubelets enden. Standardmäßig überprüft der Apiserver das Dienstzertifikat des
Kubelets nicht, was diese Verbindungen anfällig für Man-in-the-Middle-Angriffe macht
und unsicher über unzuverlässige oder öffentliche Netzwerke. Die Konfiguration der
Kubelet-Zertifikatsauthentifizierung ermöglicht es dem Apiserver, das Kubelet zu authentifizieren,
bevor es Anfragen bearbeitet, und schützt so diese Interaktionen. Diese Einrichtung
erfordert, dass TLS sowohl auf dem Apiserver als auch auf den Kubelets konfiguriert
wird, um eine sichere Kommunikation zu gewährleisten.
Auswirkung
Sie müssen TLS sowohl auf dem Apiserver als auch auf den Kubelets konfigurieren.
Prüfung
Prüfmethode 1:
HinweisKubelets können über eine Konfigurationsdatei oder Befehlszeilenargumente konfiguriert
werden. Befehlszeilenargumente haben Vorrang. Überprüfen Sie sowohl die Befehlszeilenargumente
als auch die Einträge in der Konfigurationsdatei, wenn Sie Kubelet-Konfigurationen
prüfen.
|
-
SSH in jeden Knoten und führen Sie den folgenden Befehl aus, um Details des aktiven Kubelet-Prozesses anzuzeigen:
ps -ef | grep kubelet
-
Identifizieren Sie den Speicherort der Konfigurationsdatei aus dem --config-Argument in der Ausgabe. Sehen Sie sich die Datei an mit:
sudo less /path/to/kubelet-config.json
-
Überprüfen Sie, ob eine Client-Zertifikatsbehörde-Datei konfiguriert ist:
-
Befehlszeilenargument für den Kubelet-Dienst:
--client-ca-file=/path/to/client-ca-file
-
In der Kubelet-Konfigurationsdatei:
{ "authentication": { "x509": { "clientCAFile": "/path/to/client-ca-file" } } }
-
Prüfmethode 2:
Überprüfen Sie die laufende Konfiguration eines Kubelet über den "/configz"-Endpunkt
der Kubernetes-API mit kubectl:
-
Entdecken Sie alle Knoten in Ihrem Cluster:
kubectl get nodes
-
Starten Sie einen Proxy mit kubectl auf einem lokalen Port (z. B. 8080):
kubectl proxy --port=8080
-
Öffnen Sie in einem separaten Terminal für jeden Knoten den folgenden Befehl aus:
export NODE_NAME=my-node-name curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz -
Überprüfen Sie, ob eine Client-Zertifikatsstelle konfiguriert ist, indem Sie die API-Antwort überprüfen:
{ "authentication": { "x509": { "clientCAFile": "/path/to/client-ca-file" } } }
Wiederherstellung
Methode 1:
-
SSH zu jedem Knoten.
-
Suchen Sie die Kubelet-Konfigurationsdatei:
ps -ef | grep kubelet
-
Zeigen Sie die Konfigurationsdatei an mit:
sudo less /path/to/kubelet-config.json
-
Konfigurieren Sie die Client-Zertifikatsbehörde-Datei, indem Sie den folgenden Parameter festlegen:
{ "authentication": { "x509": { "clientCAFile": "/path/to/client-ca-file" } } } -
Starten Sie den Kubelet-Dienst neu und überprüfen Sie seinen Status (Beispiel für Systeme, die systemd verwenden):
systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l
Methode 2:
-
Wenn Sie Befehlszeilenargumente verwenden, bearbeiten Sie die Kubelet-Dienstdatei, um den folgenden Parameter einzuschließen:
--client-ca-file=/path/to/client-ca-file
-
Für Systeme, die systemd verwenden, bearbeiten Sie die Datei unter /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf.
-
Starten Sie den Kubelet-Dienst neu und überprüfen Sie seinen Status (Beispiel für Systeme, die systemd verwenden):
systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l
