Network Policies Overview

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.

Key Entity Types

Network Policies match traffic based on three entities:

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

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: {}.

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

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

CNI-Specific Enhancements

Several CNI providers extend Kubernetes Network Policies with advanced capabilities:

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

• Kubernetes NetworkPolicy Documentation
• Project Calico
• Cilium
• Istio