Misconfiguring network policies to allow all traffic by default creates invisible security risks that go unnoticed until exploited.

Problem Diagnosis

Beginners often leave network policies as ANY/ANY because “everything works,” ignoring the silent exposure. A compromised pod gains unrestricted lateral movement and outbound access, enabling data exfiltration, lateral attacks, and persistence without immediate detection.

Actionable Workflow

1. Audit existing policies:

   kubectl get networkpolicies --all-namespaces  
   

   Identify clusters with no policies or default-deny violations.

2. Apply default-deny at the namespace level:

   apiVersion: networking.k8s.io/v1  
   kind: NetworkPolicy  
   metadata:  
     name: default-deny  
     namespace: <namespace>  
   spec:  
     podSelector: {}  
     policyTypes:  
       - Ingress  
       - Egress  
   

   Repeat for all namespaces.

3. Implement least-privilege policies:

   • Allow only required ports/protocols (e.g., HTTP on 80 from ingress controllers).
   • Restrict egress to known endpoints (e.g., API servers, package registries).

4. Enforce via Validating Admission Webhooks:
   Use OpenShift’s ValidatingAdmissionWebhook or OPA/Gatekeeper to block pods without approved network policies.

Concrete Policy Example

For a web app needing ingress on 80 and egress to a database:

apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
  name: web-app-policy  
spec:  
  podSelector:  
    matchLabels:  
      app: web-app  
  ingress:  
  - from:  
    - namespaceSelector:  
        matchLabels:  
          network: ingress  
    ports:  
    - protocol: TCP  
      port: 80  
  egress:  
  - to:  
    - namespaceSelector:  
        matchLabels:  
          tier: database  
    ports:  
    - protocol: TCP  
      port: 5432  

Tooling

• Network plugin support: Ensure Cilium/Calico/Weave is properly configured and healthy.
• Policy enforcement: Use OpenShift’s built-in NetworkPolicy or third-party tools like Cilium’s L7 policies.
• Visibility: Deploy network observability tools (e.g., Cilium Hubble, Weave Scope) to monitor traffic flows.

Tradeoffs

• Breakage risk: Default-deny can break legacy apps expecting open networks. Mitigate by gradually rolling policies and monitoring logs.
• Complexity: Overly restrictive policies require ongoing maintenance. Balance security with operability.

Troubleshooting

• Symptom: Pods can’t communicate despite policies.
  • Check policy podSelector matches labels.
  • Verify namespace labels match namespaceSelector.
  • Use kubectl describe networkpolicy <name> to confirm phase and status.
• Symptom: Admission webhook blocks valid workloads.
  • Review webhook logs for rejection reasons.
  • Temporarily bypass with admission.k8s.gatekeeper.sh/exempt: "true" annotation for debugging.

Prevention

• Education: Train developers to request specific network access upfront.
• Guardrails: Enforce default-deny via cluster-wide policies and admission controllers.
• Monitoring: Alert on ANY/ANY policies or unexpected traffic patterns.

In production, the cost of “working” defaults is measured in breaches, not uptime. Secure by design, not by accident.

Source thread: What’s the Kubernetes/OpenShift mistake you see beginners make most often?