More Info:
Do not generally permit containers which require the use of HostPorts.Risk Level
LowAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify all pods using
hostPort- Run on: any machine with kubectl access
- Command:
For more detail:
-
Review business / technical necessity of each
hostPortuse- For each pod found, inspect its spec and discuss with the owning team whether
hostPortis strictly required (e.g., legacy daemon, node-local listener): - Classify each as: “Required and justified” or “Not required / can be redesigned”.
- For each pod found, inspect its spec and discuss with the owning team whether
-
Design namespace-level policy for
hostPort- For namespaces where
hostPortis not needed at all, plan a policy that denies anyhostPort. - For namespaces where a few workloads must use
hostPort, plan a policy that only allows specific ports or labels and denies all otherhostPortuse. - Decide which admission control mechanism you will use (e.g., built‑in
PodSecurityadmission with restricted profiles plus an external policy engine like Kyverno / Gatekeeper, or just the external policy engine).
- For namespaces where
-
Implement or update the admission policies for each namespace
- Example: label namespace to use a restrictive Pod Security level (if compatible with workloads):
- Then add or adjust your chosen policy engine’s rules (Kyverno/OPA Gatekeeper/etc.) so that, in the target namespaces, pods with any container
ports.hostPortare denied, or only allowed per your design. (This step is policy‑engine specific and must be done by editing/creating its ClusterPolicy/Constraint manifests and applying them withkubectl apply -f <FILE>.yaml.)
- Example: label namespace to use a restrictive Pod Security level (if compatible with workloads):
-
Refactor workloads that should not use
hostPort- For each pod classified as “Not required / can be redesigned”, modify its Deployment/DaemonSet/Pod manifest to remove
hostPortfrom all container ports and rely on Services, NodePorts, or Ingress instead: - Or update the manifest in version control and apply:
- For each pod classified as “Not required / can be redesigned”, modify its Deployment/DaemonSet/Pod manifest to remove
-
Verify enforcement and residual usage
- Confirm policies are active (policy‑engine specific; e.g., list Kyverno policies):
- Attempt to create a test pod with
hostPortin a namespace where it should be denied and confirm it is rejected. - Re-run the evidence command to ensure only approved workloads (if any) still use
hostPort:
- Confirm policies are active (policy‑engine specific; e.g., list Kyverno policies):
Using kubectl
Using kubectl
kube-system, kube-public, kube-node-lease, or cloud-provider system namespaces) and review those first.<namespace> <pod-name> <hostPort-value>Any line returned indicates a Pod with at least one container exposing a hostPort. You must manually decide if each such use is strictly necessary; widespread or unexplained hostPort use is a problem.hostPort: and determine:- Is the
hostPortneeded (e.g., node-local DaemonSet, legacy integration)? - Could a Service/LoadBalancer/NodePort or Ingress replace it?
hostPort on many nodes, or general-purpose workloads with hostPort but no clear justification, indicate a problem.hostPorts ranges are wide (e.g., 0-65535) or absent (no restriction at all), this suggests insufficient restriction and is a problem; narrow, explicit ranges only for known use cases are safer.pod-security.kubernetes.io/enforce=privileged or missing baseline/restricted labels on user namespaces. While Pod Security Standards do not directly block hostPort, very permissive or unset labels suggest that no higher-level guardrails exist, increasing risk when hostPort is used.hostPort: in workload specs for general application Pods (web apps, APIs, batch jobs, etc.) is suspect. Only tightly controlled daemon-like workloads with clear operational justification should use hostPort.Automation
Automation
- Save as
report-hostport-usage.sh. - Make executable:
- Run:
- Any Pods or workloads listed in sections 1 or 2 in namespaces where hostPort is not strictly required.
- Namespaces with such usage but:
- No PodSecurity admission labels, and
- No Gatekeeper (or similar) constraints that restrict
spec.containers[].ports[].hostPort.

