Ensure All Namespaces Have Network Policies Defined

1. Confirm current CNI and NetworkPolicy support
   • On any machine with kubectl access:
     kubectl -n kube-system get pods -o wide
     kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}' ; echo
     
   • Review CNI pods (e.g., flannel, calico-node, cilium-...). If only flannel (or another non–NetworkPolicy-capable CNI) is present, plan to deploy a NetworkPolicy-capable provider (for example, Calico in “Calico + flannel” mode) following its official documentation before proceeding with policy design.
2. Inventory namespaces and existing NetworkPolicies
   • On any machine with kubectl access:
     kubectl get ns
     kubectl get networkpolicy --all-namespaces
     
   • Identify namespaces without any NetworkPolicy:
     kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{" "}{end}' | tr ' ' '\n' | while read ns; do
       [ -z "$ns" ] && continue
       count=$(kubectl get networkpolicy -n "$ns" --no-headers 2>/dev/null | wc -l | tr -d ' ')
       echo "$ns: $count"
     done
     
   • List all namespaces where the count is 0; these are in scope for remediation.
3. Classify each namespace’s intended traffic model
   • For each namespace (especially those with 0 policies), gather workload info:
     kubectl get deploy,sts,ds,svc,po -n <namespace>
     
   • With the application owners, decide for each namespace:
     • Which external CIDRs or namespaces may reach its pods (ingress).
     • Which destinations (namespaces, services, or CIDRs) its pods must contact (egress).
     • Whether intra-namespace pod-to-pod traffic should be allowed by default or restricted.
4. Design and apply baseline NetworkPolicies per namespace
   • For each namespace lacking policies, create at least a minimal, reviewed policy manifest. Examples to adapt (save and edit before applying):
     • Default deny all ingress/egress (tightest posture):
       apiVersion: networking.k8s.io/v1
       kind: NetworkPolicy
       metadata:
         name: default-deny-all
         namespace: <namespace>
       spec:
         podSelector: {}
         policyTypes:
         - Ingress
         - Egress
       
     • Allow intra-namespace traffic but deny cross-namespace by default:
       apiVersion: networking.k8s.io/v1
       kind: NetworkPolicy
       metadata:
         name: allow-same-namespace
         namespace: <namespace>
       spec:
         podSelector: {}
         policyTypes:
         - Ingress
         - Egress
         ingress:
         - from:
           - podSelector: {}
         egress:
         - to:
           - podSelector: {}
       
   • Apply with kubectl from any machine with kubectl access:
     kubectl apply -f <policy-file>.yaml
     
   • Add additional, narrower policies (per app labels) as needed to explicitly permit required ingress/egress.
5. Functionally validate impact with test pods
   • In at least one hardened namespace, run a temporary debug pod:
     kubectl run netpol-test -n <namespace> --image=busybox:1.36 --restart=Never --command -- sleep 3600
     
   • From that pod, test expected/blocked connectivity (adjust hostnames/IPs):
     kubectl exec -n <namespace> netpol-test -- wget -qO- http://<service-or-ip> || echo "blocked or error"
     
   • Confirm results align with the designed policy (required paths work, disallowed paths fail). Adjust NetworkPolicies iteratively if necessary.
6. Re-verify cluster-wide compliance
   • After policies are in place and validated, re-run evidence collection from any kubectl-capable machine:
     kubectl get networkpolicy --all-namespaces
     kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{" "}{end}' | tr ' ' '\n' | while read ns; do
       [ -z "$ns" ] && continue
       count=$(kubectl get networkpolicy -n "$ns" --no-headers 2>/dev/null | wc -l | tr -d ' ')
       echo "$ns: $count"
     done
     
   • Confirm every non-system namespace has at least one intentional, documented NetworkPolicy and that a NetworkPolicy-capable CNI is deployed and healthy.

​

Using kubectl

1. List all namespaces and see which have zero NetworkPolicies:

kubectl get ns --no-headers | awk '{print $1}' | while read ns; do
  count=$(kubectl get networkpolicy -n "$ns" --no-headers 2>/dev/null | wc -l | tr -d ' ')
  echo "$ns $count"
done

2. View namespaces with and without NetworkPolicies in a more visual way:

for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "Namespace: $ns"
  kubectl get networkpolicy -n "$ns"
  echo "----"
done

• No resources found in <namespace> namespace. → that namespace has no NetworkPolicies.
• Namespaces that only have very permissive policies (for example, a policy that selects all pods and allows all ingress and egress from/to all namespaces/CIDRs) may be effectively equivalent to having no policy and should be reviewed by a human.

3. Check which CNI plugin is running on the nodes (to confirm NetworkPolicy support):

kubectl get pods -n kube-system -o wide | egrep -i 'calico|flannel|cilium|weave|ovn|antrea'

• If you only see flannel-related pods (for example, kube-flannel-ds-*) and no NetworkPolicy-capable CNI such as calico, cilium, antrea, weave-net, etc., then NetworkPolicy objects will not be enforced even if they exist.

4. Inspect the details of existing NetworkPolicies in a specific namespace (replace NAMESPACE as needed):

kubectl get networkpolicy -n NAMESPACE -o yaml

• Policies that have podSelector: {} and allow all ingress/egress from everywhere (e.g., from: [] or to: [] or broad ipBlock ranges) can indicate a configuration that does not meaningfully restrict traffic and should be assessed manually.