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

Remediation

Remediation

Manual Steps

1. Identify namespaces with user workloads

   • Run on: any machine with kubectl access
   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
   # 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
   # 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):
     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:
     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:
     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):
     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.

Using kubectl

# 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).

---

# 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.

---

# 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.

---

# 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.

---

# 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).

Automation

#!/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.