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

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.

=(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.

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