Skip to main content
Kubernetes pods communicate freely by default, which simplifies development but poses risks in production. Network Policies close this gap by defining fine-grained rules for pod-to-pod, namespace, and external traffic. Think of them as traffic signs in your cluster that explicitly allow or deny connections.
The image illustrates a network policy concept, showing a connection from one pod to a network policy, which blocks access to another pod.

​
Key Entity Types

Network Policies match traffic based on three entities:
The image is a diagram titled "Network Policies" showing three entities: Other Pods (podSelector), Namespaces (namespaceSelector), and IP Blocks (ipBlock).

​
Defining a NetworkPolicy

A NetworkPolicy is a namespaced resource that applies to pods matching podSelector. You must also declare policyTypes (Ingress, Egress, or both) and the corresponding rules:
Network Policies only take effect when a CNI plugin that supports them is installed (e.g., Calico, Cilium).

​
Entity Selectors and IP Blocks

Use label selectors for pods and namespaces:
For IP-based rules, you can exclude subnets:

​
Layer 4 Ports and Protocols

Control ports and protocols (requires Kubernetes v1.25+ for port ranges):
  • port: Single port or starting port of a range
  • protocol: TCP or UDP (defaults to TCP)
  • endPort: End of port range (optional)

​
Default Policies

By default, all ingress and egress traffic is allowed. You can enforce a “deny all” or “allow all” baseline by using an empty podSelector: {}.
An empty podSelector: {} matches every pod in the namespace.

​
Ingress Defaults

​
Egress Defaults

You may combine Ingress and Egress in a single policy or separate them.

​
Benefits of Network Policies

  • Granular security controls by workload
  • Isolation in multi-tenant clusters
  • Compliance with GDPR, HIPAA, PCI DSS
  • Reduced attack surface by blocking unused paths
  • Consistent enforcement across applications
The image lists the benefits of network policies, including enhanced security, workload isolation, compliance, reduced attack surface, and consistency, each with an icon.

​
Limitations

Network Policies operate at layers 3 & 4 and have some constraints:
  • Cannot enforce a common gateway (service mesh can)
  • No built-in TLS termination or deep packet inspection
  • Cannot restrict host-level traffic or localhost loops
  • No native allow/deny event logging
  • Label-based only—cannot target Service objects
  • No Layer 7 (HTTP/gRPC) filtering
The image outlines the limitations of network policies, listing six specific tasks they cannot perform, such as forcing traffic through a gateway and handling TLS-related activities. It features a diagram with icons connected to a "Limitation" label.

​
CNI-Specific Enhancements

Several CNI providers extend Kubernetes Network Policies with advanced capabilities:
The image displays logos and names of various CNI (Container Network Interface) network policies, including Project Calico, Cilium, and Istio.

​
Next Steps

You now understand native Kubernetes Network Policies—how to control ingress and egress by pod, namespace, IP block, ports, and ranges. In the next lesson, we’ll apply these concepts in a real-world scenario.

​
References

Watch Video