Review hostPath use in ordinary Kubernetes workloads

Description

hostPath connects part of the node filesystem to a container. Depending on the actual mount and file permissions, an application can read or change host files, weakening the boundary between the container and node.

Avoid it for ordinary workloads without a specific operational need. Moving a Pod to kube-system alone does not make host access safe.

Potential impact

Sensitive information in host logs or configuration may be exposed.
If writes are permitted, the workload may affect node files or other workloads.

Remediation

Remove unnecessary hostPath mounts and use suitable CSI or managed storage. Even with a PVC, check whether the backing volume is hostPath.
If host access is essential, limit it to the smallest path and read-only permissions, and consider dedicated node isolation.
Restrict permission to create or modify workloads so host access cannot be expanded again.

Examples

These partial examples compare hostPath declarations. The first omits the volume name and container mount wiring, among other required configuration, so it cannot be deployed as shown. Use a supported image version for deployment too.

Before

hcl

resource "kubernetes_pod" "app_pod" {
  metadata {
    name      = "terraform-example"
    namespace = "default"
  }

  spec {
    volume {
      host_path {
        path = "/var/log"
      }
    }
  }
}

The node’s /var/log is declared as a volume source. A corresponding mount configuration is also needed before a container can use it.

After

hcl

resource "kubernetes_pod" "app_pod" {
  metadata {
    name      = "terraform-example"
    namespace = "default"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "app-container"
    }
  }
}

The hostPath declaration is removed. Check whether other volumes or permissions still provide host access.