Skip to main content

More Info:

hostPath volumes mount node filesystem paths into containers, enabling access to sensitive host files and escape. Restrict their admission.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify current use of hostPath volumes across the cluster
    • Run on: any machine with kubectl access
    • Command:
    • Review which namespaces and pods are using hostPath, and whether they are system components (e.g., in kube-system) or user workloads.
  2. Determine which namespaces require protection (user workloads)
    • Run on: any machine with kubectl access
    • Command to list namespaces:
    • Classify namespaces into:
      • System/control-plane (e.g., kube-system, kube-node-lease, kube-public)
      • Add-on/infra namespaces where hostPath may be intentionally required
      • User workload namespaces (targets for strong restriction)
  3. Design the admission policy for hostPath in user namespaces
    • Decide, per user namespace, whether:
      • hostPath should be completely disallowed, or
      • Only specific, narrowly scoped paths are allowed (e.g., a CSI driver)
    • If using an admission controller framework (e.g., ValidatingAdmissionPolicy, Kyverno, Gatekeeper), select the mechanism you will use to enforce hostPath restrictions in those namespaces.
  4. Implement or update policies to restrict hostPath in user namespaces
    • Run on: any machine with kubectl access
    • Example: create a strict ValidatingAdmissionPolicy that denies all hostPath volumes in selected namespaces (adjust namespaces as needed):
    • If you must allow specific hostPath paths, adjust the expression to allow only those paths instead of denying all hostPath.
  5. Test enforcement and handle existing workloads
    • Run on: any machine with kubectl access
    • Try to deploy a test pod with a hostPath volume into a protected namespace and confirm it is rejected:
    • For existing pods using hostPath in user namespaces, review whether they are justified; if not, plan to:
      • Update the workloads to remove hostPath, then
      • Redeploy them so that policy is applied on the next create/update.
  6. Re-verify cluster state after changes
    • Run on: any machine with kubectl access
    • Confirm no unintended hostPath use remains in user namespaces:
    • Confirm the admission policy objects are present and active:
Look for all namespaces that host user workloads (typically everything except kube-*, kubernetes-dashboard, istio-system, etc., depending on your environment). Those are the ones that must have a restriction policy.
Problem indication:
  • Any line showing hostPath.path (e.g. /var/run/docker.sock, /, /var/lib/kubelet, /etc, etc.) is a Pod that mounts the node filesystem.
  • Each such Pod must be manually reviewed for necessity and scope of the hostPath.

Problem indication:
  • Any user workload namespace with Pods listed here is using hostPath.
  • Broad or sensitive paths (like /, /var, /etc, /var/lib, /var/run) are higher risk.

Problem indication:
  • .spec.volumes[*].hostPath.path mounted with hostPath.type: "" or Directory without constraints.
  • Combined with securityContext.privileged: true, allowPrivilegeEscalation: true, or runAsUser: 0 indicates high breakout risk.

Problem indication:
  • Absence of PSPs (on clusters that still support them) or PSPs that allow hostPath volumes without restriction in namespaces where you found hostPath Pods.

Problem indication:
  • For user namespaces, labels like pod-security.kubernetes.io/enforce: privileged (or no labels at all) combined with hostPath usage means there is no baseline/restricted control to constrain such volumes.

Problem indication:
  • No admission webhooks addressing hostPath in a cluster where you depend on external policy (OPA Gatekeeper, Kyverno, etc.) to restrict such volumes.

Use these commands to:
  • Enumerate where hostPath is used.
  • Determine which namespaces run hostPath workloads.
  • Verify whether any admission control mechanism currently restricts hostPath. Human review is required to decide which hostPath uses are justified and what policies to apply to each namespace.
How to interpret the output
  • Any line in the summaries indicates a pod that is using a hostPath volume.
  • Focus review on:
    • Non‑system namespaces (third section).
    • Sensitive paths (examples: /, /var/run, /var/lib/kubelet, /etc, /var/lib/docker, /var/run/docker.sock, /run/containerd, /var/lib/containerd, /host, /proc, /sys).
    • Pods running under broadly scoped or shared service accounts.
  • Pods in user/workload namespaces using hostPath are candidates for:
    • Refactoring to use PVCs or other volume types.
    • Being constrained by admission policy (e.g., Pod Security / ValidatingAdmissionPolicy / external admission controllers) to prevent or tightly control hostPath usage.