Ein hostPath-Volume ist in Kubernetes ein Volume-Typ, der einen Datei- oder Verzeichnispfad direkt vom Dateisystem des Knotens in einen Pod einhängt. Damit kann ein Container Daten lesen oder schreiben, die auf dem Node liegen – etwa System-Logs oder Konfigurationsdateien.
Der pathType entscheidet
volumes:
- name: log-host
hostPath:
path: /var/log
type: DirectoryDirectoryOrCreate– Verzeichnis anlegen, falls es fehlt (Standardwert mit Prüfung).Directory– Verzeichnis muss bereits existieren.FileOrCreate– Datei anlegen, falls sie fehlt; der übergeordnete Ordner wird dabei nicht erzeugt.File– Datei muss bereits existieren.Socket,CharDevice,BlockDevice– für spezielle Gerätedateien.
Der leere Typ "" (keine Angabe) führt keine Prüfung durch und gilt als unsicher – Kubernetes empfiehlt, immer einen expliziten type zu setzen.
Wofür hostPath geeignet ist
Der typische Einsatz sind DaemonSets, die auf jedem Knoten genau einen Pod betreiben, etwa für Log-Sammler (/var/log), Node-Monitoring oder Agenten, die den Container-Namespace überwachen. Auch ein DaemonSet für die Knoten-Abfallentsorgung kann ein hostPath auf /var/lib/docker/containers nutzen.
Sicherheitsrisiken
hostPath durchbricht die Container-Isolation: Ein kompromittierter Container erhält direkten Zugriff auf das Dateisystem des Nodes. Werden sensible Pfade wie /etc, /var/lib/kubelet oder Root-Zertifikate gemountet, kann ein Angreifer den gesamten Knoten übernehmen. Deshalb gilt:
- hostPath nur bei klarem Bedarf einsetzen, nie für normale Anwendungsdaten.
- Die strengen Pod-Security-Profile (
baseline/restricted) verbieten hostPath – restricted erlaubt nur eingeschränkte Volume-Typen ohne hostPath. - Wer längerlebige Daten auf einem bestimmten Knoten braucht, nutzt besser einen Local PersistentVolume – der Speicher wird dann von Kubernetes verwaltet.
Zum Vergleich: Ein emptyDir ist flüchtig und verschwindet mit dem Pod, während ein PersistentVolumeClaim unabhängig vom Pod lebt und dauerhaften Speicher bereitstellt.