Egress traffic is restricted to approved destinations; no open egress to 0.0.0.0/0

Open egress to 0.0.0.0/0 means a compromised pod can exfiltrate data to any external server, download attacker tooling, or call command-and-control infrastructure — the container boundary provides zero containment for outbound traffic (NIST 800-53 SC-7, AC-4). Most production workloads communicate with a small, predictable set of destinations: a database, a few external APIs, and the Kubernetes control plane. Default Kubernetes networking permits unrestricted egress, so without explicit NetworkPolicy egress rules, a compromised pod has an outbound channel to the public internet from inside your cluster perimeter.

Add egress NetworkPolicies to every application namespace in k8s/network-policies.yaml. Start with a blanket deny, then allow specific required destinations:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              role: database
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8  # Internal VPC only
      ports:
        - protocol: TCP
          port: 443

For external API calls, use a dedicated egress gateway so the allowed destination list is auditable.