Network Policy Default Deny

K8s.

Overview

Kubernetes NetworkPolicy default-deny blocks all pod-to-pod traffic by default and explicitly allows only what services need. The result is real network segmentation inside the cluster, not just at the perimeter.

• Default-deny. No pod-to-pod traffic without an explicit allow rule. Compromised pods cannot pivot freely.
• Per-namespace policies. Each namespace carries its own posture matching team boundaries.
• Per-app allow rules. Specific service-to-service traffic explicitly allowed. Anything else gets denied.
• CNI requirement plus ingress and egress. Calico, Cilium, or equivalent enforces the policy; both directions can be locked down to match the threat model.

The approach

Three habits make default-deny operationally sound: apply per-namespace, write allow rules per app, and monitor denies as a standing signal during rollout.

• Namespace default-deny. Apply the default-deny policy per namespace. New services inherit isolation from creation.
• Per-app allow rules. Service-to-service rules per application. The allow rules document inter-service communication.
• Cilium for L7 policy. When path-level or method-level policy matters, Cilium provides L7-aware rules.
• Monitor denies plus documented rules. Hubble or equivalent surfaces denies during rollout; per-app allow rules live in source control.

Why this compounds

Each tightened policy reduces breach blast radius for the lifetime of the workload. Compounded across the cluster, the security posture transforms.

• Reduced breach impact. Compromised pods cannot pivot through the cluster. Lateral movement requires breaching every hop.
• Service inventory. Allow rules document service-to-service communication. The policy file doubles as a service catalog.
• Compliance. NetworkPolicy matches enterprise zero-trust requirements. The posture opens regulated markets.
• Year-one investment, year-two habit. The first namespace is heavy lift. By year two, every new namespace ships default-deny from creation.