More Info:
Containers sharing the host network namespace can access node-level network interfaces and bypass network controls. Restrict admission of hostNetwork containers via namespace policies.Risk Level
HighAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify pods currently using
hostNetwork(any machine with kubectl access): -
For each affected namespace that should host only user workloads, create or update a
BaselinePod Security admission policy that disallowshostNetwork(any machine with kubectl access). Example for namespacemy-namespace:If you need finer control (e.g., allow for specific system workloads), instead create a custom admission policy (ValidatingAdmissionPolicy/PolicyBinding, Gatekeeper, or Kyverno) that rejects pods withspec.hostNetwork: trueexcept for explicitly allowed service accounts. -
Review exceptions before tightening policies (any machine with kubectl access):
For any pod that legitimately requires
hostNetwork(e.g., CNI components), ensure it runs in a dedicated “system” namespace with an explicit exception in your admission policy, or is excluded by your policy’s namespace/label selectors. -
Update workload manifests to remove
hostNetwork: truewhere not strictly required (any machine with kubectl access). For each affected pod/deployment:In the editor, remove or set: -
Redeploy any workloads that previously relied on
hostNetworkonly after confirming they function correctly behind normal Kubernetes networking and network policies (any machine with kubectl access). Use your CI/CD or: -
Verification (any machine with kubectl access):
Confirm the output is:
Using kubectl
Using kubectl
Note: The above uses Kyverno as an example admission controller. If Kyverno (or a similar admission controller) is not installed, install and configure one first; kubectl alone cannot enforce admission without such a controller.
Automation
Automation

