> ## 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 The Admission Of Containers Sharing The Host Network Namespace

### More Info:

Containers sharing the host network namespace can access node network interfaces and bypass network segmentation. Their admission should be restricted via Pod Security Admission policies.

### Risk Level

High

### Address

Security

### Compliance Standards

* CIS AKS

### Triage and Remediation

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

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify namespaces with user workloads**
           * Run on: any machine with kubectl access
           ```sh theme={null}
           kubectl get ns
           ```
           Decide which namespaces contain user workloads (exclude core system namespaces such as `kube-system`, `kube-node-lease`, `kube-public`, `gatekeeper-system`, etc., unless you intentionally run user apps there).

        2. **Review current Pod Security Admission labels on those namespaces**
           * Run on: any machine with kubectl access
           ```sh theme={null}
           # Replace NAMESPACE with each user-workload namespace
           kubectl get ns NAMESPACE -o jsonpath='{.metadata.name}{"\t"}{.metadata.labels}{"\n"}'
           ```
           Confirm whether `pod-security.kubernetes.io/enforce` is set to `restricted` (preferred) or a weaker level, and whether any `warn` labels are in use.

        3. **Check for existing Pods using hostNetwork in each user-workload namespace**
           * Run on: any machine with kubectl access
           ```sh theme={null}
           # All pods using hostNetwork across the cluster
           kubectl get pods --all-namespaces -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}'
           ```
           For each listed Pod, determine if `hostNetwork: true` is strictly required for its function or is an unnecessary elevation.

        4. **Decide the policy level per namespace based on business and technical need**
           * For most user-workload namespaces, plan to enforce `restricted`, which disallows `hostNetwork: true`.
           * For namespaces that legitimately need `hostNetwork` (for example, certain node networking agents), consider:
             * Keeping them unlabelled or at `baseline`, and
             * Documenting the justification and who is allowed to deploy there.

        5. **Apply or tighten Pod Security Admission labels on user-workload namespaces**
           * Run on: any machine with kubectl access
           * To enforce restricted policy on a specific namespace (recommended default):
             ```sh theme={null}
             kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
             ```
           * Optionally add a warning label at `baseline` cluster-wide to highlight less secure specs without blocking:
             ```sh theme={null}
             kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
             ```
           Reassess any CI/CD manifests to ensure they no longer request `hostNetwork: true` in namespaces where `restricted` is enforced.

        6. **Verify enforcement and resulting behavior**
           * Confirm labels:
             ```sh theme={null}
             kubectl get ns --show-labels
             ```
           * Attempt to create a test Pod with `hostNetwork: true` in a `restricted` namespace to confirm it is rejected (do not deploy in production namespace if you want to avoid noise; use a non-critical test namespace with the same labels):
             ```sh theme={null}
             cat <<'EOF' | kubectl apply -f -
             apiVersion: v1
             kind: Pod
             metadata:
               name: hostnetwork-test
               namespace: NAMESPACE
             spec:
               hostNetwork: true
               containers:
               - name: pause
                 image: k8s.gcr.io/pause:3.9
             EOF
             ```
           The admission request should be denied by Pod Security Admission in a `restricted` namespace, demonstrating that new hostNetwork pods are minimized.
      </Accordion>

      <Accordion title="Using kubectl">
        ```bash theme={null}
        # 1) List all namespaces and their Pod Security labels
        # Run on: any machine with kubectl access
        kubectl get ns --show-labels
        ```

        **What to look for (problem indicators)**

        * Namespaces with user workloads that are **missing** `pod-security.kubernetes.io/enforce` or have it set to `privileged` or `baseline`.
        * Namespaces where you **expect restrictions** but see no `pod-security.kubernetes.io/warn` label either (no visibility into policy violations).

        ***

        ```bash theme={null}
        # 2) Show only Pod Security labels for easier review
        kubectl get ns -o custom-columns=NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\\.kubernetes\\.io/enforce,WARN:.metadata.labels.pod-security\\.kubernetes\\.io/warn
        ```

        **What to look for**

        * `ENFORCE` is empty or `privileged`/`baseline` in namespaces that run user workloads.
        * `WARN` is empty where you want to be warned about non‑compliant Pods.

        ***

        ```bash theme={null}
        # 3) Check for Pods using hostNetwork in all namespaces
        kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.hostNetwork}{"\n"}{end}' \
          | grep -w "true"
        ```

        **What to look for**

        * Any line where `hostNetwork` is `true` in **non‑system namespaces** (i.e., not `kube-system`, `gatekeeper-system`, etc.).
        * These Pods are currently using the host network and may not be blocked by Pod Security Admission.

        ***

        ```bash theme={null}
        # 4) Focus on a specific namespace with user workloads (example: "prod")
        NAMESPACE=prod

        # Show Pod Security labels on that namespace
        kubectl get ns "$NAMESPACE" --show-labels

        # List Pods in that namespace that use hostNetwork
        kubectl get pods -n "$NAMESPACE" -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.hostNetwork}{"\n"}{end}' \
          | grep -w "true" || echo "No hostNetwork pods found in $NAMESPACE"
        ```

        **What to look for**

        * Namespace `prod` has no `pod-security.kubernetes.io/enforce=restricted` label but contains Pods with `hostNetwork=true`.
        * This combination indicates a higher‑risk configuration needing human review.

        ***

        ```bash theme={null}
        # 5) (If admission results are logged) Describe a Pod that attempted hostNetwork
        # to see if Pod Security Admission is blocking or only warning
        POD=example-pod
        NAMESPACE=prod

        kubectl describe pod "$POD" -n "$NAMESPACE"
        ```

        **What to look for**

        * Events mentioning `pod-security.kubernetes.io`:
          * Messages like “violates PodSecurity ‘restricted’” for hostNetwork use (means enforcement is working).
          * Only warning annotations or no mention of PodSecurity (means hostNetwork might not be blocked).
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Run on: any machine with kubectl access and context set to the target cluster

        set -euo pipefail

        echo "=== 1) Namespaces and their Pod Security Admission labels ==="
        kubectl get ns \
          -o custom-columns=NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\\.kubernetes\\.io/enforce,WARN:.metadata.labels.pod-security\\.kubernetes\\.io/warn \
          | sed 's/<none>//g'

        cat <<'EOF'

        Interpretation:
        - For namespaces with user workloads, you generally EXPECT:
          - ENFORCE=restricted
          - Optionally WARN=baseline (or stricter)
        - Potential issues:
          - ENFORCE is empty or weaker than 'restricted' on user-workload namespaces.
          - No PSA labels set on namespaces that run user workloads.
        EOF

        echo
        echo "=== 2) Pods that request hostNetwork ==="
        # Cluster-wide view of any pod with hostNetwork: true
        kubectl get pods -A \
          -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\t"}{.spec.nodeName}{"\n"}{end}' \
          | sort || true

        cat <<'EOF'

        Interpretation:
        - Any line here indicates a pod using hostNetwork.
        - Review for each:
          - Namespace: is this a user-workload namespace or a system/control-plane namespace?
          - ServiceAccount: is it expected to need host-level networking?
          - Node: does the placement make sense from a security perspective?

        If you see hostNetwork pods in user-workload namespaces that are not explicitly approved,
        that is a potential problem.

        EOF

        echo "=== 3) Namespaces that both hostNetwork pods AND lack enforce=restricted ==="
        # Join namespace lists: hostNetwork-using namespaces vs restricted-enforced ones
        hostnet_ns_file="$(mktemp)"
        restricted_ns_file="$(mktemp)"

        kubectl get pods -A \
          -o jsonpath='{range .items[?(@.spec.hostNetwork==true)]}{.metadata.namespace}{"\n"}{end}' \
          | sort -u > "${hostnet_ns_file}" || true

        kubectl get ns \
          -o jsonpath='{range .items[?(@.metadata.labels.pod-security\.kubernetes\.io/enforce=="restricted")]}{.metadata.name}{"\n"}{end}' \
          | sort -u > "${restricted_ns_file}"

        echo "Namespaces with hostNetwork pods but without enforce=restricted:"
        comm -23 "${hostnet_ns_file}" "${restricted_ns_file}" || true

        rm -f "${hostnet_ns_file}" "${restricted_ns_file}"

        cat <<'EOF'

        Interpretation:
        - Any namespace listed here:
          - Currently has at least one pod using hostNetwork, AND
          - Does NOT have pod-security.kubernetes.io/enforce=restricted
        - These namespaces should be reviewed first. If they contain user workloads,
          consider tightening Pod Security Admission labels in line with your policy.

        EOF

        echo "=== 4) Optional: detailed manifest snippets for hostNetwork pods (for review) ==="
        echo "To review details of a specific pod, run:"
        echo "  kubectl -n <namespace> get pod <pod-name> -o yaml | sed -n '1,80p'"
        ```

        What output indicates a problem:

        * Section 1:
          * User-workload namespaces with no `pod-security.kubernetes.io/enforce` label, or with a value weaker than your policy (e.g., unset where you expect `restricted`).
        * Section 2:
          * Any listed pod in a user-workload namespace using `hostNetwork` that is not explicitly justified by your security/design requirements.
        * Section 3:
          * Any namespace shown here is a higher-priority concern: it has `hostNetwork` pods but lacks `enforce=restricted`, so admission controls are not aligned with the benchmark guidance.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>