NetworkPolicy

NetworkPolicy uses label selectors to define policy targets and traffic sources, decoupling security rules from ephemeral IP addresses. A policy applies to pods matching podSelector, while ingress.from and egress.to rules use podSelector and namespaceSelector to identify allowed peers. This enables dynamic membership: as pods are created or destroyed, the policy automatically applies to new pods with matching labels without manual rule updates. The selector model supports AND/OR logic—combining namespaceSelector and podSelector within a single from entry requires both to match, while multiple from entries create a logical OR.

NetworkPolicy provides directional traffic control through distinct ingress and egress rule sets:

• Ingress rules specify which sources can send traffic TO the selected pods
• Egress rules specify which destinations the selected pods can send traffic TO

A critical default behavior: pods are non-isolated until a NetworkPolicy selects them. Once any policy selects a pod, it becomes isolated for that direction. If only ingress rules are defined, all egress traffic is still allowed. If only egress rules are defined, all ingress traffic is still allowed. To fully lock down a pod, both ingress and egress policies must be applied. This allows incremental hardening—start with ingress restrictions, then add egress controls.

NetworkPolicy operates at the namespace boundary, enabling multi-tenant isolation within a single cluster. Using namespaceSelector, a policy can allow or deny traffic from entire namespaces based on their labels. Common patterns include:

• Deny-all default policy: A policy selecting all pods with empty ingress/egress rules blocks all cross-pod traffic
• Allow-from-same-namespace: Permits traffic only from pods within the same namespace
• Allow-from-specific-namespaces: Grants access only to labeled namespaces like environment: production

This namespace-scoped model maps directly to organizational boundaries—teams, environments, and compliance zones—without requiring separate clusters for isolation.

NetworkPolicy enforces Layer 4 controls by specifying allowed ports and protocols on each rule. Each ingress.from or egress.to entry can include a ports array defining:

• port: A numeric port or named port defined on the target pod
• protocol: TCP, UDP, or SCTP (defaults to TCP if omitted)
• endPort: Kubernetes 1.22+ supports port ranges via endPort, enabling rules like "allow ports 8000-8100"

This granularity allows precise service exposure. For example, a database pod can accept TCP 5432 from application pods while blocking all other ports, even from the same source. Named ports provide abstraction—referencing port: http instead of port: 80 decouples policy from specific port numbers.

Beyond pod and namespace selectors, NetworkPolicy supports CIDR notation for defining IP block ranges in ipBlock fields. This enables rules for traffic to or from:

• External services outside the cluster (e.g., 192.168.1.0/24)
• The node's own IP for host-network services
• Specific external APIs that pods must access

ipBlock supports an except field to carve out exceptions from a larger CIDR range. For example, allow 10.0.0.0/8 except 10.0.1.0/24 to block a specific subnet. Important caveat: ipBlock rules apply to all traffic from those IPs, regardless of pod identity—combine with pod selectors for defense-in-depth. External traffic control is essential for air-gapped environments where pods may need limited access to on-premises services.

NetworkPolicy is a Kubernetes API resource only—it requires a Container Network Interface (CNI) plugin that implements the NetworkPolicy specification to actually enforce the rules. Without a compatible CNI, policies are stored but not enforced. Common CNIs with NetworkPolicy support include:

• Cilium: Full policy support plus eBPF-based Layer 7 filtering and observability
• Calico: Mature implementation with global network policies extending beyond namespaces
• Weave Net: Native policy enforcement with automatic mesh networking

Critical verification: Always confirm your CNI supports the specific features you're using—endPort ranges, SCTP protocol, and ipBlock.except are not universally implemented. In disconnected environments, the CNI must be pre-staged in the private registry and must not require external license validation calls.

A protocol where both client and server authenticate each other using X.509 certificates, ensuring encrypted and identity-verified communication between services. In the context of NetworkPolicy:

• Policy enforcement point: mTLS provides cryptographic identity that NetworkPolicy rules can reference
• Certificate rotation: Automated by service mesh control planes like Istio or Linkerd
• Sidecar vs. sidecarless: Traditional proxies or eBPF-based implementations like Cilium

Combining NetworkPolicy with mTLS creates a defense-in-depth posture: NetworkPolicy blocks unauthorized connections at L3/L4, while mTLS ensures that permitted connections are authenticated and encrypted end-to-end.

A built-in Kubernetes admission controller that enforces security standards at the namespace level, replacing the deprecated PodSecurityPolicy. PSA defines three policy levels:

• Privileged: Unrestricted, for system workloads
• Baseline: Prevents known privilege escalations
• Restricted: Follows Pod hardening best practices

While NetworkPolicy controls east-west traffic between pods, PSA controls pod capabilities and host access. Together they implement a comprehensive zero-trust posture: PSA prevents a compromised pod from escaping its container, while NetworkPolicy limits its blast radius by restricting lateral movement.

An architectural paradigm where no implicit trust is granted to any pod, node, or service regardless of its network location. Key principles applied to Kubernetes NetworkPolicy:

• Micro-segmentation: Every pod-to-pod connection requires explicit allow rules
• Least privilege: Policies grant only the minimum required ingress/egress paths
• Continuous verification: Identity-based policies that adapt to pod lifecycle changes
• Default deny: All traffic is blocked unless explicitly permitted by a NetworkPolicy

In sovereign AI infrastructure, zero-trust networking ensures that even if an attacker compromises a model serving pod, they cannot pivot to access the training data store or the private container registry.

The configuration that enables encryption at rest for data stored in the Kubernetes etcd key-value store. NetworkPolicy objects are stored as resources in etcd, making their protection critical:

• Encryption providers: AES-CBC, AES-GCM, or KMS plugins for external key management
• Resource-level granularity: Encrypt specific resource types like Secrets and NetworkPolicies
• Key rotation: Automated rotation of encryption keys without cluster downtime

In disconnected environments, etcd encryption ensures that if physical storage media is compromised, the NetworkPolicy definitions—which reveal the cluster's internal service topology—remain unreadable to attackers.