Network Policy and the Discipline of Isolation

Doctrine

Network policy is where the cluster learns restraint. It defines what may speak, to whom, and by which path.

Kubblai doctrine: boundaries are part of reliability. Unbounded communication is unbounded blast radius.

CNI caveats you must acknowledge

NetworkPolicy enforcement is CNI-dependent. Some CNIs enforce only certain layers; some have performance tradeoffs. You must test policy behavior in your environment, not rely on assumption.

Policy that is not enforced is theatre.

Default-deny as a governed rollout

Default-deny is powerful and disruptive. Roll it out by namespace class, with clear exceptions and visibility into dropped traffic.

Operators who flip default-deny without observability are manufacturing incidents.

Example: baseline policy

A minimal pattern: allow within namespace, allow DNS, deny everything else by default (adjust to your needs).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: baseline
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Operational practice

Policy rollout requires a measurement loop: dropped traffic visibility, application error budgets, and staged enforcement.

Treat policy like a release: canary, validate, expand.