More Info:
Do not generally permit containers to be run with the hostNetwork flag set to true.Risk Level
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List pods using hostNetwork (discovery)
Run on: any machine with kubectl access -
Identify user workload namespaces that allow hostNetwork (review)
Run on: any machine with kubectl access
Review which of the above pods are in user workload namespaces (exclude kube-system and other control-plane/system namespaces). For each user namespace you decide should not allow hostNetwork, proceed to the next step. For namespaces that legitimately need hostNetwork (e.g., CNI, ingress), document the exception instead of applying the restriction. -
Create a baseline admission policy to deny hostNetwork (example Kyverno)
Run on: any machine with kubectl access
If you use Kyverno, create a ClusterPolicy denying hostNetwork for pods in selected namespaces (replace<NAMESPACE1>,<NAMESPACE2>with a comma‑separated list of target namespaces):Adapt the tool and syntax to your existing admission controller (e.g., OPA Gatekeeper, ValidatingAdmissionPolicy) but keep the same intent: match Pods in selected namespaces and deny whenspec.hostNetwork == true. -
Handle existing hostNetwork pods in restricted namespaces (migration)
Run on: any machine with kubectl access
For each affected namespace from step 2, list existing hostNetwork pods again and plan replacement without hostNetwork:For each listed workload (Deployment/DaemonSet/StatefulSet/Job, etc.), edit its manifest to remove or sethostNetwork: falseunderspec.template.spec, then apply:Replace pods created directly (not via controllers) by deleting and recreating them with hostNetwork disabled. -
Optionally scope exceptions per-namespace (refine policy)
Run on: any machine with kubectl access
For namespaces where specific workloads must use hostNetwork, narrow your policy instead of blanket denying the namespace. Example Kyverno rule that allows hostNetwork only for pods with a specific label:Then explicitly label exception pods/workloads: -
Verification (re-run the audit with expectation)
Run on: any machine with kubectl access
Re-run the audit and confirm no pods withspec.hostNetwork=trueexist in namespaces where you applied restrictions:For user namespaces meant to be restricted, ensure all lines showis_pod_hostnetwork: falseandis_compliant: true; any remaining non-compliant pods should be investigated or migrated.
Using kubectl
Using kubectl
Automation
Automation

