Profilanwendbarkeit: Stufe 1
Wenn
kube-proxy läuft und durch eine kubeconfig-Datei konfiguriert ist, stellen Sie sicher, dass
die Proxy-kubeconfig-Datei Berechtigungen von 644 oder restriktiver hat.Die
kube-proxy kubeconfig-Datei steuert verschiedene Parameter des kube-proxy-Dienstes auf dem Worker-Knoten. Sie sollten die Dateiberechtigungen einschränken,
um die Integrität der Datei zu wahren. Die Datei sollte nur von den Administratoren
des Systems beschreibbar sein.
HinweisDie Standardberechtigungen der Proxy-Kubeconfig-Datei sind 644.
|
Auswirkung
Zu großzügige Dateiberechtigungen erhöhen das Sicherheitsrisiko für die Plattform.
Prüfung
Google Cloud-Konsole verwenden
- Gehen Sie zu Kubernetes Engine.
- Klicken Sie auf den gewünschten Cluster, um die Detailseite zu öffnen, und klicken Sie dann auf den gewünschten Knotenpool, um die Detailseite des Knotenpools zu öffnen.
- Notieren Sie den Namen des gewünschten Knotens.
- Gehen Sie zu VM-Instanzen.
- Suchen Sie den gewünschten Knoten und klicken Sie auf SSH, um eine SSH-Verbindung zum Knoten herzustellen.
Verwendung der Befehlszeile
Methode 1: SSH zu den Worker-Knoten
- Um zu überprüfen, ob der Kubelet-Dienst läuft:
sudo systemctl status kubelet
- Die Ausgabe sollte
Active: active (running) since...zurückgeben. Führen Sie den folgenden Befehl auf jedem Knoten aus, um die entsprechende kubeconfig-Datei zu finden:ps -ef | grep kubelet
- Die Ausgabe des obigen Befehls sollte etwas Ähnliches wie
--kubeconfig/var/lib/kubelet/kubeconfigzurückgeben, was den Speicherort der kubeconfig-Datei darstellt. - Führen Sie diesen Befehl aus, um die Berechtigungen der kubeconfig-Datei zu erhalten:
stat -c %a /var/lib/kubelet/kubeconfig
- Die Ausgabe des obigen Befehls gibt Ihnen die Berechtigungen der kubeconfig-Datei. Überprüfen Sie, ob eine Datei angegeben ist und existiert, dass die Berechtigungen 644 oder restriktiver sind.
Methode 2: Erstellen und Ausführen eines privilegierten Pods
- Run a pod that is privileged enough to access the host's file system by deploying
a pod that uses the hostPath volume to mount the node's file system into the pod.
Here's an example of a simple pod definition that mounts the root of the host to /host
within the pod:
apiVersion: v1 kind: Pod metadata: name: file-check spec: volumes: - name: host-root hostPath: path: / type: Directory containers: - name: nsenter image: busybox command: ["sleep", "3600"] volumeMounts: - name: host-root mountPath: /host securityContext: privileged: true
- Speichern Sie dies in einer Datei (z. B. file-check-pod.yaml) und erstellen Sie das
Pod:
kubectl apply -f file-check-pod.yaml
- Sobald das Pod läuft, können Sie sich in das Pod einloggen, um die Dateiberechtigungen
auf dem Knoten zu überprüfen:
kubectl exec -it file-check -- sh
- Jetzt befinden Sie sich in einer Shell innerhalb des Pods, aber Sie können über das
/host-Verzeichnis auf das Dateisystem des Knotens zugreifen und die Berechtigungsstufe
der Datei überprüfen:
ls -l /host/var/lib/kubelet/kubeconfig
- Überprüfen Sie, ob eine Datei angegeben ist und ob sie existiert, dass die Berechtigungen 644 oder restriktiver sind.
Wiederherstellung
Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System)
auf jedem Worker-Knoten aus:
chmod 644 <proxy kubeconfig file>
