Kubernetes Security: Sharing the host namespace

hostNetwork, hostPID, or hostIPC weaken pod isolation and increase host-level risk. Disable host namespace sharing unless strictly required and controlled.

Problem

Enabling hostNetwork, hostPID, or hostIPC removes key isolation boundaries and increases blast radius after compromise. Most application workloads do not need this access. Action: default all host namespace flags to false and treat every exception as privileged.

Description

hostNetwork bypasses pod network isolation and can collide with node services. hostPID exposes host process metadata that helps attacker reconnaissance. hostIPC opens shared-memory channels between pod and node processes. Action: block these flags in baseline namespaces with admission policy.

Mixed isolation models also create operational risk. Monitoring, incident response, and audit rules become inconsistent when some pods bypass defaults. Action: keep required host-namespace workloads in a dedicated namespace with clear ownership, stricter network policy, and explicit runtime controls.

Pod Security Standards discourage host namespace usage because least-privilege boundaries are one of Kubernetes’ strongest protections. Manual review alone does not scale for busy teams. Action: enforce deny-by-default policy and allow exceptions only through a labeled, approved path.

Use this rollout checklist to keep exceptions controlled:

  • Deny hostNetwork, hostPID, and hostIPC by default in admission policy.
  • Require risk acceptance, owner, and expiry date for each exception.
  • Pair each exception with non-root execution, dropped capabilities, and network restrictions.
  • Review and remove old exceptions on a fixed monthly cadence.

Treat verification as part of the rule, not optional cleanup. Action: automate a static check, a build check, and a runtime smoke check in the default CI pipeline so regressions are caught before review.

  • Static check: fail when the disallowed pattern appears in Dockerfile or manifest.
  • Build check: run a minimal image build to confirm the secure pattern is valid.
  • Runtime check: start the workload and assert expected behavior with one deterministic probe.

Examples of code

Problematic code

apiVersion: v1
kind: Pod
metadata:
  name: diagnostics
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "sleep 3600"]

Verified code

apiVersion: v1
kind: Pod
metadata:
  name: diagnostics
spec:
  hostNetwork: false
  hostPID: false
  hostIPC: false
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "sleep 3600"]

Related rules