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


### Description
Host namespaces (Process ID namespace, Inter-Process Communication namespace, and network namespace) allow access to shared information and can be used to elevate privileges. Pods should not be allowed access to host namespaces.

**Restricted Fields**
* spec.hostNetwork
* spec.hostPID
* spec.hostIPC

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

### Risks
When `hostNetwork` is set to `true`, we encounter risks such as:

* `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.

When `hostPID` is set to `true`, we encounter risks such as:

* `Viewing Host Processes`: Running ps from within a pod with `hostPID: true` allows you to see all processes running on the host, including those from other pods.

* `Finding Sensitive Information`: There's a chance you could discover credentials like passwords, tokens, or keys. With these, you could potentially escalate privileges within the cluster, gain access to other namespaces, or even elevate to cluster admin.

* `Terminating Processes`: You could also terminate any process on the node, creating a denial-of-service situation. 

When `hostIPC` is set to `true`, we encounter risks such as:

* `Access to Shared Data`: Allows a pod to access inter-process communication (IPC) mechanisms shared by the host or other pods using the host’s IPC namespace. 

* `Inspecting Shared Memory (`/dev/shm`)`: You can access the `/dev/shm` directory, which is shared between the host and any pod with this setting enabled. The sensitive data that is stored here might be exposed.

* `Manipulating IPC Mechanisms`: You can inspect and potentially interact with existing IPC mechanisms, such as shared memory, semaphore arrays, or message queues, using tools like `/usr/bin/ipcs`. This could lead to altering of communication channels between processes.

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

### References
#### Configuration Settings
The below configuration indicates that if the deployed resource contains one of `hostPID` or `hostIPC` or `hostNetwork` in their `spec` field, then the only acceptable value is `false` to be conformant with this security control. If those fields are not present to begin with, then the resource is conformant by default.

```bash
=(hostPID): "false"
=(hostIPC): "false"
=(hostNetwork): "false"
```

#### Resource Example
Below is a `Deployment` resource example where all the three fields (`hostPID`, `hostIPC`, and `hostNetwork`) are set to `false`. Even if one or two of them are present, they should be set to `false`.
```bash
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gooddeployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      hostPID: false
      hostIPC: false
      hostNetwork: false
      containers:
      - name: container01
        image: dummyimagename
```text