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



### Description
Windows pods offer the ability to run [HostProcess containers](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod) which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. HostProcess pods are stable as of Kubernetes 1.26.

**Restricted Fields**
* spec.securityContext.windowsOptions.hostProcess
* spec.containers[*].securityContext.windowsOptions.hostProcess
* spec.initContainers[*].securityContext.windowsOptions.hostProcess
* spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess

**Allowed Values**
* Undefined/nil
* false

### Risks
HostProcess determines if a container should be run as a 'Host Process' container. All of a Pod's containers must have the same effective
HostProcess value (it is not allowed to have a mix of HostProcess containers and non-HostProcess containers). In addition, if HostProcess is true then HostNetwork must also be set to true. When `hostProcess` is set to `true`, we will encounter the following risks:

* `Privileged Access`: Windows HostProcess containers run with elevated privileges on the host node. This grants them the ability to interact directly with the Windows host system,

* `Network Traffic Snooping`: Enabling `hostNetwork` allows a pod to access the node's network namespace, which includes the ability to monitor all network traffic on the node. This could lead to sensitive data exposure if an attacker manages to deploy a malicious pod that can snoop on network communications.

* `Access Services Bound to Localhost`: You can gain access to services that are only available on the host's loopback interface or are otherwise restricted by network policies. These services could present opportunities for privilege escalation.

* `Bypassing Network Policies`: When a pod is deployed with `hostNetwork: true`, it can bypass restrictive network policies applied to the namespace. This occurs because the pod is bound to the host's network interfaces rather than being confined to the network restrictions at the pod level.

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

### References
#### Configuration Settings
The below configuration indicates that if the deployed resource contains one of `ephemeralContainers` or `initContainers` or `containers` in their `spec` field, **AND** if `securityContext.windowsOptions.hostProcess`,  field is present, then the only acceptable value is `false` to be conformant with this security control. If the `securityContext.windowsOptions.hostProcess` field is not present, then the resource is conformant by default.

```bash
=(ephemeralContainers):
  - =(securityContext):
    =(windowsOptions):
      =(hostProcess): "false"
=(initContainers):
  - =(securityContext):
    =(windowsOptions):
      =(hostProcess): "false"
containers:
  - =(securityContext):
    =(windowsOptions):
      =(hostProcess): "false"
```

#### Resource Example
Below is a `Deployment` resource example where `securityContext.windowsOptions.hostProcess` is set to `false` for both `initContainers` and `containers`.

```bash
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gooddeployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      hostNetwork: true
      initContainers:
      - name: initcontainer01
        image: dummyimagename
        securityContext:
          windowsOptions:
            hostProcess: false
      - name: initcontainer02
        image: dummyimagename
      containers:
      - name: container01
        image: dummyimagename
        securityContext:
          windowsOptions:
            hostProcess: false
```text