Ensure CNI Plugin Supports Network Policies

# 1) List all installed CNI plugins (pods in kube-system)
# Run on: any machine with kubectl access
kubectl get pods -n kube-system -o wide

# 2) Check if any NetworkPolicies exist cluster-wide
kubectl get networkpolicies --all-namespaces

# 3) Inspect network policies in a given namespace
# Replace NAMESPACE with a real namespace, e.g. "default"
kubectl get networkpolicy -n NAMESPACE -o wide
kubectl describe networkpolicy -n NAMESPACE POLICY_NAME
kubectl get networkpolicy -n NAMESPACE -o yaml

# 4) Verify whether default namespaces have baseline protection
kubectl get ns
# For each namespace of interest, inspect its policies:
for ns in default kube-system kube-public; do
  echo "Namespace: $ns"
  kubectl get networkpolicy -n "$ns"
done

# 5) Test that policies are enforced (requires existing policies)
# 5a) Get two pods in the same namespace
kubectl get pods -n NAMESPACE -o wide

# 5b) From one pod, try reaching another (adjust POD_NAME and TARGET_IP)
kubectl exec -n NAMESPACE -it POD_NAME -- ping -c 3 TARGET_IP
kubectl exec -n NAMESPACE -it POD_NAME -- nc -vz TARGET_IP TARGET_PORT

# 6) Check if a "default deny" exists in important namespaces
# Example label-based search (may or may not return results)
kubectl get networkpolicy -A -l "policy-type=default-deny" -o yaml

#!/usr/bin/env bash
# Purpose:
# - Report which CNI is installed
# - Check if it is one that supports NetworkPolicy
# - Summarize NetworkPolicy usage by namespace
#
# Run on: any machine with kubectl access and cluster-admin permissions

set -euo pipefail

echo "=== 1. Detecting CNI plugin(s) ==="
echo "-> Inspecting kube-system namespace for common CNI DaemonSets and Pods..."
kubectl get ds,pod -n kube-system -o wide | grep -Ei 'calico|cilium|weave|flannel|canal|antrea|ovn|amazon-vpc-cni|aws-node|azure|gke|cni' || \
  echo "No obvious CNI DaemonSet/Pod found by name pattern."

echo
echo "=== 1a. Detailed CNI pod images (kube-system) ==="
kubectl get pods -n kube-system -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -Ei 'calico|cilium|weave|flannel|canal|antrea|ovn|cni|aws-node|azure|gke' || \
  echo "No obvious CNI container images matched."

cat <<'EOF'

INTERPRETATION (CNI):
- You MUST confirm from documentation whether your detected CNI supports Kubernetes NetworkPolicy.
- Common cases:
  * Supports NetworkPolicy: calico, cilium, antrea, weave-net (with NP), canal, ovn-kubernetes, GKE-native, Azure CNI (with NP), etc.
  * Does NOT enforce NetworkPolicy (or only partially): basic flannel, some cloud-native CNIs unless NP mode is enabled.
- If you see only 'flannel' or a cloud CNI known not to enforce NetworkPolicy, traffic segmentation via NetworkPolicy is NOT effective -> PROBLEM.

EOF

echo "=== 2. Cluster-wide NetworkPolicy usage ==="
echo "-> Count NetworkPolicy objects per namespace"
echo "NAMESPACE  NP_COUNT"
kubectl get networkpolicy --all-namespaces --no-headers 2>/dev/null \
  | awk '{print $1}' | sort | uniq -c | awk '{printf "%-10s %s\n", $2, $1}' || \
  echo "No NetworkPolicy resources found in any namespace."

echo
echo "=== 2a. Namespaces with ZERO NetworkPolicies ==="
# List all namespaces, join with those that have NPs
ns_with_np="$(kubectl get networkpolicy --all-namespaces --no-headers 2>/dev/null | awk '{print $1}' | sort -u || true)"
echo "Namespaces without any NetworkPolicy defined:"
kubectl get ns --no-headers | awk '{print $1}' | while read -r ns; do
  if ! grep -qx "$ns" <<< "$ns_with_np"; then
    echo "  - $ns"
  fi
done

cat <<'EOF'

INTERPRETATION (NetworkPolicy presence):
- Namespaces with ZERO NetworkPolicies are likely allowing all traffic by default.
- If your CNI DOES enforce NetworkPolicy, you should:
  * At least have baseline policies in sensitive namespaces, and
  * Consider a namespace-wide "default deny" (ingress/egress) where appropriate.

EOF

echo "=== 3. Detect namespaces missing a 'default deny' style policy ==="
echo "-> Heuristic: look for NetworkPolicies that set podSelector: {} and policyTypes including Ingress/Egress"
echo
echo "Namespaces and policies that LOOK like 'default deny' candidates:"
kubectl get networkpolicy --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(
        (.spec.podSelector | tostring) == "{}"
      )
    | [
        .metadata.namespace,
        .metadata.name,
        ( .spec.policyTypes // [] | join(",") ),
        ( ( .spec.ingress // [] | length ) | tostring ),
        ( ( .spec.egress // [] | length ) | tostring )
      ]
    | @tsv
  ' 2>/dev/null \
  | awk 'BEGIN{printf "%-20s %-30s %-20s %-8s %-8s\n","NAMESPACE","POLICY","POLICY_TYPES","INGRESS","EGRESS"}
         {printf "%-20s %-30s %-20s %-8s %-8s\n",$1,$2,$3,$4,$5}' || \
  echo "No NetworkPolicies found that look like namespace-wide defaults."

cat <<'EOF'

INTERPRETATION (default deny):
- A robust least-privilege design usually:
  * Starts with a namespace-wide deny-all (podSelector: {} and policyTypes: [Ingress,Egress]),
  * Then adds specific allow rules.
- Potential PROBLEMS:
  * Sensitive namespaces (e.g., containing workloads with secrets or external exposure) have:
    - No NetworkPolicies at all, or
    - Only allow rules but no clear default deny foundation.
  * The CNI does not enforce NetworkPolicy, making any defined policies ineffectual.

EOF

echo "=== 4. Verification summary ==="
echo "- Confirm from vendor docs that the detected CNI ENFORCES NetworkPolicy."
echo "- Review:"
echo "  * Namespaces with no NetworkPolicies"
echo "  * Namespaces lacking a clear default deny-style policy"
echo "If CNI does not support NetworkPolicy, or policies do not follow least privilege, this check is NOT satisfied."