NetworkPolicy Cross-Namespace Egress Monitor

The Incident (What Does the Error Mean?)

You'll see this surface in pod logs, curl timeouts, or via a service mesh like Istio/Linkerd as:

Error: dial tcp <ClusterIP>:<port>: i/o timeout
# or from a CNI like Calico:
EGRESS traffic denied by NetworkPolicy: source=<pod> destination=<namespace>/<service>

Kubernetes NetworkPolicy is default-deny by omission. The moment you attach any NetworkPolicy to a pod, all traffic not explicitly permitted is dropped — including egress. If your policy has an ingress block but no egress block, every outbound packet from that pod is silently killed. No ICMP unreachable. No RST. Just a timeout.

Immediate consequence: Any pod selected by this policy cannot reach services in other namespaces — databases, auth services, external APIs routed through a gateway namespace. This is a full service communication blackout.

The Attack Vector / Blast Radius

This is a misconfiguration-as-outage pattern. The blast radius depends on how broadly the podSelector is scoped:

• If podSelector: {} (matches all pods in namespace) — entire namespace is egress-isolated. Every microservice calling a dependency in another namespace fails simultaneously.
• Cascading failure path: frontend → can't reach auth-service (different namespace) → returns 500 → circuit breaker trips → frontend marks itself unhealthy → load balancer pulls it → full service outage.
• In a zero-trust posture, this is intended behavior applied at the wrong scope. The danger is that developers add a NetworkPolicy for ingress hardening and unknowingly nuke all egress without realizing NetworkPolicy is additive-only and non-reversible without an explicit allow rule.
• DNS is the first casualty. kube-dns lives in kube-system. If your egress policy doesn't explicitly allow UDP/TCP 53 to kube-system, DNS resolution fails before any application-level connection is even attempted. This makes the error appear as a generic connection failure, masking the real cause.

Prevention in CI/CD

1. OPA/Gatekeeper — Enforce egress DNS rule presence:

Write a Rego policy that rejects any NetworkPolicy with policyTypes containing Egress but no egress rule targeting port 53. Gate this in your admission webhook.

2. Checkov scan in pipeline:

checkov -f networkpolicy.yaml --check CKV_K8S_7
# CKV_K8S_7: Ensure NetworkPolicy is not overly permissive

Add custom Checkov checks for missing DNS egress rules — the built-in checks don't catch this by default.

3. Kyverno policy — Require namespace labels before NetworkPolicy references them:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-ns-label-for-egress
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-namespaceselector-label
      match:
        resources:
          kinds: [NetworkPolicy]
      validate:
        message: "Egress namespaceSelector must use kubernetes.io/metadata.name label."
        pattern:
          spec:
            egress:
              - to:
                  - namespaceSelector:
                      matchLabels:
                        "kubernetes.io/metadata.name": "?*"

4. Automated integration test: Run a netpol-tester job (e.g., networkpolicy-viewer or cyclonus) as a post-deploy step in staging. It enumerates all NetworkPolicies and validates actual pod-to-pod reachability against declared intent. Fail the pipeline if reachability matrix diverges from spec.

5. Label hygiene: Enforce via CI that every namespace has kubernetes.io/metadata.name set (it's auto-set in K8s 1.21+, but custom labels used in selectors must be validated to exist before the policy is applied).