Skip to main content
Let’s walk through a common Kubernetes security scenario you might encounter in an interview, audit, or post-incident review. You’re auditing a production cluster and discover a pod running as root with a hostPath mount of the node’s root filesystem (/). That pod can read and write anything on the host. Your manager asks:
  1. How bad is this?
  2. How do we fix it without breaking production?
Short answer: a privileged pod with an unrestricted hostPath can lead to full node compromise and often cluster-wide escalation. Below we explain why, show the attack surfaces, and give a pragmatic, low-friction mitigation plan you can roll out safely.

​
Why this is so dangerous (attack vectors)

A pod with access to the node’s root filesystem can extract secrets and operational credentials from the node, then impersonate node-level components to escalate access.
  • Kubelet credentials: The pod can read kubelet credentials on the node and use them to talk to the API server. Depending on RBAC rules and kubelet privileges, an attacker could read secrets, create resources, or escalate further.
  • Container runtime socket: The pod can access the container runtime socket (for example, /var/run/docker.sock or /run/containerd/containerd.sock) and control the runtime directly to spawn privileged containers on the node — bypassing the API server entirely.
The image is a diagram illustrating a Kubernetes security vulnerability, showing an attack chain where kubelet credentials are stolen, the kubelet is impersonated to access the API, and all secrets are pulled from etcd.
If an attacker compromises such a pod, it’s not just a pod-level incident — you can have a fully compromised node and, in many clusters, that can lead quickly to a cluster-wide compromise.
The image illustrates a security vulnerability in a Kubernetes cluster setup, highlighting an attack chain involving credential theft and secret extraction. It emphasizes the risk with the phrase "Why So Bad?" and details an attack chain on the right.

​
Immediate containment (short-term actions)

If you suspect a pod is compromised: cordon the node, isolate the workload, and avoid restarting containers on the same node until you investigate. Collect forensic artifacts (logs, filesystem snapshots) before making further changes.

​
How to fix this without causing an outage

Follow a cautious, staged approach: discover what the workload truly needs, reduce scope, harden the pod, and then roll out cluster-wide guardrails in audit mode first.
  1. Figure out what the workload actually needs
  • Many workloads do not need the entire host filesystem; they may only require a specific directory such as /var/log. Confirm requirements with the workload owner.
  • Some components legitimately need broader access (e.g., CSI drivers or certain system agents). Coordinate with owners before making changes.
The image shows a slide with the heading "Fix it w/o Outage," discussing the needs of a pod, with options for a "Log Collector" and "CSI Driver" related to access requirements.
  1. Reduce scope and apply a restrictive securityContext
  • Replace hostPath: / with a single specific path the app needs.
  • Mark mounts readOnly: true when possible.
  • Disable privileged and set allowPrivilegeEscalation: false.
  • Run the container as a non-root user (runAsNonRoot: true).
  • Use seccompProfile: RuntimeDefault.
  • Drop all capabilities and only add the minimal set required (for example, NET_BIND_SERVICE if binding to ports < 1024).
  • Set readOnlyRootFilesystem: true if supported.
Example container spec snippet:
  1. Enforce cluster-wide controls (carefully)
  • Start with Pod Security Admission (PSA) and apply the restricted profile for namespaces that don’t need exceptions.
  • For fine-grained policies use OPA Gatekeeper or Kyverno to:
    • Block hostPath mounts targeting root (/).
    • Block privileged containers.
    • Block pods running as UID 0 (root).
    • Deny access to container runtime sockets from user workloads.
  • Run policies in audit (log-only) mode for at least a week to detect false positives and understand legitimate exceptions. Remediate those exceptions with workload owners before switching to enforce mode.
Run new policies in audit mode first. Monitor violations, remediate legitimate cases, and only then move to enforce to avoid unexpected outages.

​
Quick remediation checklist

​
References and further reading

Final takeaway: a privileged pod mounting the host filesystem is a node- (and often cluster-) level risk. The practical mitigation path is: discover real workload needs, narrow the hostPath, harden the pod securityContext, and deploy cluster policy guardrails in audit mode before enforcing.

Watch Video