Host networking, hostPath, and mount propagation — node-level access patterns

Many DaemonSet workloads need to read or write host-level state: container logs in /var/log, kernel parameters in /proc and /sys, BPF maps in /sys/fs/bpf, network interfaces. Kubernetes exposes this integration through hostPath volumes, hostNetwork / hostPID / hostIPC fields, and mountPropagation. Each one is a security boundary. This lesson covers what each does, when it is required, and how to configure it safely.

hostPath volumes

A hostPath volume mounts a directory or file from the node into the Pod:

spec:
  template:
    spec:
      containers:
      - name: log-collector
        volumeMounts:
        - name: var-log
          mountPath: /var/log
          readOnly: true
      volumes:
      - name: var-log
        hostPath:
          path: /var/log
          type: Directory

The type field controls validation:

DirectoryOrCreate is the most common cause of security incidents. A path typo (e.g., /var/llog) creates the directory on the node with root ownership. A vulnerability in the container writes files there; the files persist on the node.

hostNetwork

hostNetwork: true puts the Pod in the node’s network namespace. The Pod’s localhost is the node’s localhost; the Pod’s IP is the node’s IP.

spec:
  template:
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet

The dnsPolicy: ClusterFirstWithHostNet is required when the Pod’s resolv.conf should still resolve cluster DNS (the Pod is in the host network namespace but should still use CoreDNS for cluster service discovery).

flowchart LR
    A["Pod with hostNetwork: true"] --> B[Node's network namespace]
    B --> C[Node's IP]
    B --> D[Node's localhost]
    B --> E["Node's /etc/resolv.conf<br/>unless overridden"]

Used by CNI agents (Cilium, Calico) and monitoring exporters (node-exporter) that need to bind to host addresses.

The security implication: the Pod shares the node’s network. A compromised Pod can bind any port on the node’s IP; it can impersonate the node’s services.

hostPID

hostPID: true puts the Pod in the node’s PID namespace. The Pod can see every process on the node, not just its own containers’ processes.

spec:
  template:
    spec:
      hostPID: true
      containers:
      - name: node-exporter
        # can read /proc/1/cmdline, see all processes

Used by monitoring exporters and security agents that need to enumerate processes or read process metadata.

The security implication: the Pod can read /proc/*/environ (env vars of other Pods, including Secrets if mounted as env vars), /proc/*/cmdline, and /proc/*/maps. A compromised monitoring exporter has access to secrets.

hostIPC

hostIPC: true shares the node’s IPC namespace. Used by agents that need to share System V IPC primitives. Rare in modern Kubernetes; included for completeness.

mountPropagation

By default, mounts in a Pod are not visible to the host, and mounts on the host are not visible to the Pod. The mountPropagation field changes this:

spec:
  template:
    spec:
      containers:
      - name: storage-agent
        volumeMounts:
        - name: ceph-data
          mountPath: /var/lib/ceph
          mountPropagation: Bidirectional

Bidirectional is required when the Pod needs to mount a volume that the host can also see (e.g., Ceph’s OSD directory, where the Pod mounts the OSD and the host kernel sees the device). It is also a security boundary: any mount on the host is visible in the Pod.

The security boundary

flowchart TB
    A[hostPath + writable] --> B[Host-level arbitrary write]
    C[hostNetwork] --> D[Bind any port on host IP]
    E[hostPID] --> F[Read all process env vars and cmdline]
    G[Bidirectional mountPropagation] --> H[All host mounts visible]

Each one is a privileged capability. Production DaemonSets use them because the workload requires it, but each must be reviewed:

• Audit the image source. A privileged DaemonSet running an unsigned, unpinned image is a node-level compromise waiting to happen.
• Review the path. A typo in hostPath can mount the wrong directory.
• Verify the type. DirectoryOrCreate is dangerous; use Directory for known paths.
• Read-only mounts wherever possible. The log collector reads; the storage agent writes. Match the mount to the workload’s actual need.
• Drop Linux capabilities. Even with privileged: true, the container should drop capabilities it does not need. Modern CNI agents and exporters drop capabilities selectively.

Common DaemonSet configurations

# Log collector — read-only, hostPath, hostNetwork for log shipping
spec:
  template:
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      tolerations: [{operator: Exists}]
      containers:
      - name: fluent-bit
        # ...
        securityContext:
          runAsNonRoot: true
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: var-log
          mountPath: /var/log
          readOnly: true
      volumes:
      - name: var-log
        hostPath: {path: /var/log, type: Directory}

# CNI agent — privileged, hostPath for BPF, hostPath
spec:
  template:
    spec:
      hostNetwork: true
      hostPID: true    # some CNIs need this
      containers:
      - name: cilium
        securityContext:
          privileged: true
        volumeMounts:
        - name: bpf
          mountPath: /sys/fs/bpf
          mountPropagation: Bidirectional
      volumes:
      - name: bpf
        hostPath: {path: /sys/fs/bpf, type: DirectoryOrCreate}

# Monitoring exporter — hostNetwork, hostPID for /proc, read-only hostPath
spec:
  template:
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: node-exporter
        securityContext:
          runAsNonRoot: true
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
      volumes:
      - name: proc
        hostPath: {path: /proc, type: Directory}

Quiz

Production discipline

• Audit every hostPath mount. The path, the type, the read-only flag. Every one of these is a security-relevant decision.
• Treat hostNetwork, hostPID, hostIPC as privileges. Each must have a written justification in the manifest comment.
• Use readOnlyRootFilesystem: true for non-storage agents. The DaemonSet’s writable layers should be empty.
• Pin the image by digest. A latest tag on a privileged DaemonSet is a node-level risk.
• Verify mountPropagation matches the workload. A Pod that needs Bidirectional is a Pod that can see every host mount. Use it deliberately.

DaemonSets are the bridge between Kubernetes and the host. The bridge is bidirectional: the host sees the Pod’s workload, the Pod sees the host’s state. Operators who understand the bridge know what their DaemonSets can do.