---
title: "Disallow Host Path"
url: https://docs.nirmata.io/docs/policy-sets/podsecurity/baseline/disallow-host-path/
---



### Description
HostPath volumes let Pods use host directories and volumes in containers. Using host resources can be used to access shared data or escalate privileges and should not be allowed. Using the hostPath volume type presents many security risks. If you can avoid using a hostPath volume, you should. For example, define a local PersistentVolume, and use that instead.

**Restricted Fields**
* spec.volumes[*].hostPath

**Allowed Values**
* Undefined/nil

### Risks
Using `hostPath` volumes can introduce significant security risks to your Kubernetes cluster. Here are some potential risks associated with allowing `hostPath`:

1. `Privilege Escalation`: If a Pod with a `hostPath` volume is compromised, an attacker could gain access to sensitive files on the host machine. For instance, mounting a directory such as `/var/log` could allow an attacker to symlink sensitive files, read private SSH keys, or even manipulate service account tokens stored on the host.

2. `Container Escape`: Allowing `hostPath` volumes can lead to container escape. For example, mounting `/proc/sys/kernel/core_pattern` allows an attacker to modify kernel parameters that could lead to executing commands on the host itself.

3. `Data Exposure and Manipulation`: By mounting sensitive directories like `/etc/kubernetes/manifests`, an attacker could modify static Pod definitions, causing unintended deployments or persistence on the cluster.

4. `Host Manipulation`: Mounting critical directories such as `/var/lib/kubelet/pods` can expose Pod-specific data, including tokens for service accounts, secrets, and configMaps, which could be used to move laterally across the cluster.

5. `Resource Misuse`: Pods with access to the host's filesystem can abuse mounted paths to perform unauthorized actions, such as creating persistent data outside of the Kubernetes control, leading to resource leaks or disk space exhaustion.

6. `Configuration Drift`: Pods that use `hostPath` can behave unpredictably depending on the specific files and directories available on different nodes. This inconsistency can lead to unexpected behavior and difficult-to-troubleshoot issues.

### Kyverno Policy
Refer to the Nirmata curated policies - [disallow-host-path.yaml](https://github.com/nirmata/kyverno-policies/blob/main/pod-security/baseline/disallow-host-path/disallow-host-path.yaml)

### References
#### Configuration Settings
The below configuration indicates that HostPath volumes are forbidden. The field `spec.volumes[*].hostPath` must be unset in order to be conformant with this security control. If it is not present, then the resource is conformant by default.

```bash
=(volumes):
  - X(hostPath): "null"
```

#### Resource Example
Below is a `Deployment` resource example where even though `volumes` field is present, it does not have a `hostPath` field. If present, it should be set to `null`.

```bash
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gooddeployment02
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: container01
        image: dummyimagename
        volumeMounts:
          - name: temp
            mountPath: /scratch
      volumes:
      - name: temp
        emptyDir: {}
```text