Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

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:
Entity TypeSelector KeyDescription
Other PodspodSelectorSelect pods by labels
NamespacesnamespaceSelectorSelect namespaces by labels
IP BlocksipBlockSpecify CIDR ranges and exclusions
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: 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: app1
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: frontend
        - podSelector:
            matchLabels:
              app: app2
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
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: 
# Namespace selector with expressions
namespaceSelector:
  matchExpressions:
    - key: environment
      operator: In
      values: ["prod", "staging"]

# Pod selector with labels
podSelector:
  matchLabels:
    app: frontend
For IP-based rules, you can exclude subnets: 
ipBlock:
  cidr: 172.17.0.0/16
  except:
    - 172.17.1.0/24

​
Layer 4 Ports and Protocols

Control ports and protocols (requires Kubernetes v1.25+ for port ranges): 
- to:
    - podSelector:
        matchLabels:
          app: database
  ports:
    - port: 5432
      protocol: TCP
      endPort: 5434
  • 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

# Deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
# Allow all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-allow-ingress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - {}

​
Egress Defaults

# Deny all egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Egress
---
# Allow all egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-allow-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - {}
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:
CNI PluginAdvanced Features
Project CalicoGlobal policies, BGP routing, NetworkSets
CiliumLayer 7 HTTP/gRPC filtering, eBPF datapath, Hubble insights
IstioService mesh policies, mTLS, ingress/egress gateways
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