Resolved

Kubernetes NetworkPolicy blocks external HTTPS egress to public APIs

Kubernetes
NetworkPolicy
DevOps
Security
Networking
Cloud
Debugging
YAML

Kubernetes NetworkPolicy using podSelector instead of ipBlock prevents external HTTPS connections to services like Hugging Face | Job fails with ConnectionError despite network policy being applied

Fixing External Connectivity in Kubernetes NetworkPolicy for Bloomberg Indexing Job

Issue

A Kubernetes job responsible for indexing Bloomberg datasets failed to connect to external APIs (e.g., Hugging Face Hub, Azure OpenAI) despite having a NetworkPolicy in place. All HTTPS egress attempts resulted in connection timeouts, preventing the job from accessing required public resources.

Culprit

The NetworkPolicy configuration incorrectly used podSelector for egress rules, which restricts traffic to pods within the same namespace. Since external services (like Hugging Face or Azure OpenAI) are outside the cluster, this selector type blocked all external communication. Specifically:

  • The policy allowed internal pod-to-pod communication but denied external IP access.
  • External services require ipBlock selectors to define allowed CIDR ranges, not pod-based selectors.
  • DNS resolution and HTTPS/HTTP access were inadvertently locked out due to misconfigured rules.

Solution

The NetworkPolicy was updated to:

  • Replace podSelector with ipBlock: Allowed external IP ranges (e.g., 0.0.0.0/0) for HTTPS (port 443) and HTTP (port 80) traffic.
  • Add explicit DNS rules: Used namespaceSelector to permit DNS queries (ports 53 UDP/TCP) to the kube-system namespace.
  • Separate rules for different traffic types: Maintained clear distinctions between internal (pod-to-pod), external (HTTPS/HTTP), and DNS traffic.

Outcome: The job now successfully accesses external APIs, resolving connection errors while adhering to Kubernetes NetworkPolicy best practices (e.g., least privilege, explicit allow rules).