Kubernetes Network Policy: Prove Reachability Before Declaring Isolation

A network policy manifest is evidence of intent. It is not evidence that traffic is blocked. The cluster’s networking implementation must enforce the policy, selectors must match the intended workloads, and other policies can affect the resulting access.

I would migrate one service boundary at a time, starting with a dependency map and a repeatable set of reachability probes.

Establish the default, then name the exceptions

For a dedicated namespace, this manifest expresses a default denial for selected pod ingress and egress:

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

It is an isolation baseline, not a complete service configuration. Additional policies must allow required application traffic and DNS. Restrict DNS to the cluster’s actual resolver endpoints and required protocols rather than allowing every destination on port 53.

Kubernetes documents that network policies are additive and require a supporting network plugin. It also describes the interaction of source egress and destination ingress policies in the NetworkPolicy reference. Those details matter when reviewing why a supposedly denied path still works.

Review selectors as authority

A pod label used by a policy effectively grants network reachability. If a workload owner can freely add a privileged label or deploy into a trusted namespace, the policy may not represent the intended trust boundary.

Review who can mutate labels, create workloads, and change policies. Separate namespace and deployment permissions where the threat model requires it. Network segmentation does not replace service authentication or object-level authorization; it reduces reachable paths.

Avoid treating an observed traffic graph as a complete allowlist. It may omit disaster recovery, infrequent batch jobs, certificate renewal, or newly enabled features. Ask each service owner to validate dependencies and identify which ones are truly required.

Make the rollout falsifiable

A probe suite should establish both that legitimate traffic succeeds and that forbidden traffic fails. Run it from the relevant source workloads, not just from a convenient administrator pod with different labels.

Include calls to another tenant’s service, administrative ports, the public internet, and expected database endpoints. Exercise both IPv4 and IPv6 if the cluster uses both. Record the policy revision and probe identities with the result so a future investigation can reproduce the claim.

I would begin in a representative nonproduction environment, then use a small production service with a clear rollback owner. Monitor denied traffic and application errors together; a quiet firewall dashboard is unhelpful if customers cannot complete transactions.

The leadership deliverable is an owned network contract: required dependencies, forbidden paths, enforcement evidence, and an exception process. Track services with verified boundaries rather than counting YAML files. A policy that nobody can safely change will eventually become a broad allow rule during an outage.