Skip to main content

More Info:

Do not generally permit containers which require the use of HostPorts.

Risk Level

Low

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify all pods using hostPort
    • Run on: any machine with kubectl access
    • Command:
      For more detail:
  2. Review business / technical necessity of each hostPort use
    • For each pod found, inspect its spec and discuss with the owning team whether hostPort is strictly required (e.g., legacy daemon, node-local listener):
    • Classify each as: “Required and justified” or “Not required / can be redesigned”.
  3. Design namespace-level policy for hostPort
    • For namespaces where hostPort is not needed at all, plan a policy that denies any hostPort.
    • For namespaces where a few workloads must use hostPort, plan a policy that only allows specific ports or labels and denies all other hostPort use.
    • Decide which admission control mechanism you will use (e.g., built‑in PodSecurity admission with restricted profiles plus an external policy engine like Kyverno / Gatekeeper, or just the external policy engine).
  4. 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.hostPort are 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 with kubectl apply -f <FILE>.yaml.)
  5. 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 hostPort from all container ports and rely on Services, NodePorts, or Ingress instead:
    • Or update the manifest in version control and apply:
  6. Verify enforcement and residual usage
    • Confirm policies are active (policy‑engine specific; e.g., list Kyverno policies):
    • Attempt to create a test pod with hostPort in 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:
Look for namespaces that contain user workloads (typically not kube-system, kube-public, kube-node-lease, or cloud-provider system namespaces) and review those first.
Output format:
<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.
Review each occurrence of hostPort: and determine:
  • Is the hostPort needed (e.g., node-local DaemonSet, legacy integration)?
  • Could a Service/LoadBalancer/NodePort or Ingress replace it?
Multiple apps using the same hostPort on many nodes, or general-purpose workloads with hostPort but no clear justification, indicate a problem.
If 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.
Look for labels like 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.
Any 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.
How to run (any machine with kubectl access):
  1. Save as report-hostport-usage.sh.
  2. Make executable:
  1. Run:
Problem indicators in the output:
  • 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.

Additional Reading: