> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Minimize Admission Of Containers Sharing The Host Network Namespace

### More Info:

Sharing the host network namespace exposes node network interfaces and bypasses network policies. Enforce policies that restrict admission of hostNetwork containers.

### Risk Level

High

### Address

Security

### Compliance Standards

* CIS OKE

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify all pods using `hostNetwork` across the cluster**
           * Run on: any machine with kubectl access
           * Command:
             ```bash theme={null}
             kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'
             ```
           * Review: Determine which are platform/infra components (e.g., CNI, DNS, ingress) vs. user workloads; list user workloads that use `hostNetwork`.

        2. **Review existing admission controls / policies per namespace**
           * Run on: any machine with kubectl access
           * Commands:
             ```bash theme={null}
             kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -o wide
             kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -o wide
             kubectl get limitranges,resourcequotas,networkpolicies,configmaps -A
             ```
           * Review: For each user-workload namespace, check if there is any admission controller (e.g., OPA Gatekeeper, Kyverno, custom webhooks) or policy that explicitly restricts `spec.hostNetwork: true`. Note which namespaces lack such protection.

        3. **Determine business/operational need for each `hostNetwork` pod**
           * For each user-workload pod from step 1, review deployment manifests and owners:
             ```bash theme={null}
             kubectl get pod -n <NAMESPACE> <POD_NAME> -o yaml
             ```
           * Decide with application owners whether `hostNetwork` is truly necessary (e.g., low-latency network access, node-local ports). Document which workloads can drop `hostNetwork` and which must retain it.

        4. **Plan and apply namespace-level admission policies to restrict `hostNetwork`**
           * Choose or confirm your admission mechanism (e.g., Kyverno, OPA Gatekeeper, custom webhook).
           * For each user-workload namespace that should **disallow** `hostNetwork`, create/update a policy that:
             * Denies new pods (and controllers: Deployments, DaemonSets, etc.) with `spec.hostNetwork: true`, except for explicitly allowed labels/namespaces.
           * Apply policy manifests from any machine with kubectl access:
             ```bash theme={null}
             kubectl apply -f <POLICY_MANIFEST>.yaml
             ```
           * Ensure policies are scoped per-namespace as required by your governance.

        5. **Refactor or reconfigure existing workloads to stop using `hostNetwork` where possible**
           * For each pod that does not strictly require `hostNetwork`:
             * Update the workload manifest (Deployment/StatefulSet/DaemonSet/etc.) to remove or set `hostNetwork: false`.
           * Apply the updated manifest from any machine with kubectl access:
             ```bash theme={null}
             kubectl apply -f <UPDATED_WORKLOAD>.yaml
             ```
           * Coordinate with application teams and schedule changes to avoid disruption; be aware that networking behavior (ports, policies, source IPs) will change.

        6. **Verify effectiveness of policies and remaining `hostNetwork` usage**
           * Confirm that new `hostNetwork` pods are blocked in protected namespaces (expect admission denial):
             ```bash theme={null}
             kubectl run test-hostnet --image=busybox --restart=Never \
               --overrides='{"apiVersion":"v1","kind":"Pod","spec":{"hostNetwork":true,"containers":[{"name":"c","image":"busybox","command":["sleep","3600"]}]}}' \
               -n <PROTECTED_NAMESPACE>
             ```
           * Re-run the audit query to ensure only justified workloads use `hostNetwork`:
             ```bash theme={null}
             kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'
             ```
           * Confirm that any remaining `hostNetwork` pods are documented, approved exceptions and that corresponding namespaces still have admission policies in place.
      </Accordion>

      <Accordion title="Using kubectl">
        ### Using kubectl

        #### 1. List pods that request `hostNetwork`

        Run on: any machine with kubectl access.

        ```sh theme={null}
        kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork' \
          --no-headers | grep -E 'true$' || echo "No pods with hostNetwork=true found"
        ```

        **Problem indication:** Any line returned (namespace/name with `HOSTNETWORK` = `true`) is using the host network and must be reviewed for necessity and risk.

        To see details for a specific pod:

        ```sh theme={null}
        kubectl get pod <pod-name> -n <namespace> -o yaml
        ```

        Review `.spec.hostNetwork: true` and the pod’s purpose.

        ***

        #### 2. Discover whether pod security controls exist

        **a. Pod Security admission labels on namespaces (if using built-in PSA)**

        ```sh theme={null}
        kubectl get ns --show-labels
        ```

        **Problem indication:** Namespaces with user workloads that lack any `pod-security.kubernetes.io/*` labels, or are labeled with an overly-permissive level (e.g., `privileged`) likely do not restrict `hostNetwork`.

        Check a specific namespace:

        ```sh theme={null}
        kubectl get ns <namespace> -o yaml
        ```

        Inspect `metadata.labels` for `pod-security.kubernetes.io/enforce` (or `audit`/`warn`). Levels `restricted`/`baseline` are stricter; `privileged` means essentially unrestricted.

        ***

        **b. PodSecurityPolicy (legacy clusters only)**

        Check if PSP is enabled and list existing policies:

        ```sh theme={null}
        kubectl get psp
        ```

        If PSPs exist, inspect them:

        ```sh theme={null}
        kubectl get psp <psp-name> -o yaml
        ```

        **Problem indication:** Policies that apply to user workloads (via RBAC bindings) and allow `hostNetwork: true` without clear justification or scoping. In a PSP YAML, look at:

        ```yaml theme={null}
        spec:
          hostNetwork: true
        ```

        This indicates the policy permits host networking.

        ***

        **c. Admission webhooks / OPA / Gatekeeper / Kyverno (if used)**

        List all Mutating/ValidatingWebhookConfigurations:

        ```sh theme={null}
        kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io
        kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io
        ```

        Inspect each security-related webhook:

        ```sh theme={null}
        kubectl get validatingwebhookconfiguration <name> -o yaml
        kubectl get mutatingwebhookconfiguration <name> -o yaml
        ```

        **Problem indication:** No webhook configurations that reference policies about `spec.hostNetwork`, or policy engines (OPA Gatekeeper, Kyverno, etc.) installed without any constraints/policies targeting `hostNetwork`. You will need to review the webhook/policy definitions themselves (in the policy engine’s CRDs) to determine whether `hostNetwork` is restricted.

        ***

        #### 3. Verify after policy decisions

        After you adjust policies (outside the scope of kubectl alone), re-run:

        ```sh theme={null}
        kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork' \
          --no-headers | grep -E 'true$' || echo "No pods with hostNetwork=true found"
        ```

        If any `HOSTNETWORK=true` pods remain, they should be explicitly approved exceptions; otherwise, they indicate a remaining policy gap.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        set -euo pipefail

        # This script must run on any machine with kubectl access and correct kubeconfig.
        # It reports all Pods and workload templates that request hostNetwork=true.

        echo "=== Pods currently using hostNetwork ==="
        kubectl get pods -A -o json \
          | jq -r '
            .items[]
            | select(.spec.hostNetwork == true)
            | [
                .metadata.namespace,
                .metadata.name,
                (.metadata.ownerReferences[0].kind // "Pod"),
                (.metadata.ownerReferences[0].name // "-"),
                (.spec.serviceAccountName // "default")
              ]
            | @tsv' \
          | awk 'BEGIN{OFS="\t"; print "NAMESPACE","POD","OWNER_KIND","OWNER_NAME","SERVICE_ACCOUNT"}1'

        echo
        echo "=== Workload templates allowing hostNetwork (may create hostNetwork pods in future) ==="
        # Deployments
        kubectl get deploy -A -o json \
          | jq -r '
            .items[]
            | select(.spec.template.spec.hostNetwork == true)
            | ["Deployment",
               .metadata.namespace,
               .metadata.name,
               (.spec.template.spec.serviceAccountName // "default")
              ]
            | @tsv' \
          | awk 'BEGIN{OFS="\t"; print "KIND","NAMESPACE","NAME","SERVICE_ACCOUNT"}1'

        # DaemonSets
        kubectl get ds -A -o json \
          | jq -r '
            .items[]
            | select(.spec.template.spec.hostNetwork == true)
            | ["DaemonSet",
               .metadata.namespace,
               .metadata.name,
               (.spec.template.spec.serviceAccountName // "default")
              ]
            | @tsv' \
          | awk 'BEGIN{OFS="\t"; print "KIND","NAMESPACE","NAME","SERVICE_ACCOUNT"}1'

        # StatefulSets
        kubectl get sts -A -o json \
          | jq -r '
            .items[]
            | select(.spec.template.spec.hostNetwork == true)
            | ["StatefulSet",
               .metadata.namespace,
               .metadata.name,
               (.spec.template.spec.serviceAccountName // "default")
              ]
            | @tsv' \
          | awk 'BEGIN{OFS="\t"; print "KIND","NAMESPACE","NAME","SERVICE_ACCOUNT"}1'

        echo
        echo "=== Namespaces without any NetworkPolicy (weaker isolation for any hostNetwork use) ==="
        kubectl get ns -o json \
          | jq -r '
            .items[].metadata.name' \
          | while read -r ns; do
              count=$(kubectl get networkpolicy -n "$ns" --no-headers 2>/dev/null | wc -l | tr -d ' ')
              if [ "$count" -eq 0 ]; then
                echo "$ns"
              fi
            done

        echo
        echo "=== Interpretation ==="
        cat <<'EOF'
        Any line shown above indicates a configuration to review:

        - "Pods currently using hostNetwork":
          Each listed pod is already running with hostNetwork=true and bypasses
          normal namespace-level network isolation and most NetworkPolicy controls.

        - "Workload templates allowing hostNetwork":
          Any listed Deployment, DaemonSet, or StatefulSet will create pods with
          hostNetwork=true. These should exist only where strictly necessary and
          should be covered by explicit admission / policy exceptions.

        - "Namespaces without any NetworkPolicy":
          Host-networked workloads in these namespaces are of higher concern, since
          there is no NetworkPolicy layer at all. Consider introducing policies and/or
          restricting hostNetwork via admission controls in these namespaces.

        Use this report to decide:
        - Which existing hostNetwork uses are truly required.
        - Where to add or tighten admission controls and NetworkPolicy.
        EOF
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>