Skip to main content

Chapter 9.3 - Network Policies

Learning Objectives​

By the end of this chapter, you will be able to:

  • Understand what Network Policies are
  • Create Network Policies to isolate traffic
  • Configure ingress and egress rules
  • Use selectors to target Pods
  • Implement network segmentation
  • Understand the limitations

Introduction​

Network Policies allow you to control network traffic between Pods in a Kubernetes cluster. They provide application-level network segmentation.

What is a Network Policy?​

A Network Policy defines rules that control network traffic between Pods. It allows you to:

  • Allow or block ingress (incoming) traffic
  • Allow or block egress (outgoing) traffic
  • Filter by namespace, labels, or IPs

Important: Network Policies require a CNI that supports them (Calico, Cilium, etc.).

Default Behavior​

Without Network Policy​

By default: All Pods can communicate with all other Pods.

With Network Policy​

Isolation: Only authorized traffic is allowed.

Basic Example​

Network Policy: Isolate a Namespace​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}  # All Pods
  policyTypes:
  - Ingress
  - Egress

Result: No ingress or egress traffic is allowed in the production namespace.

Network Policy: Allow Internal Traffic​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production

Result: Only traffic from the production namespace is allowed.

Selectors​

Pod Selector​

Target specific Pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-network-policy
spec:
  podSelector:
    matchLabels:
      app: web
      tier: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api

Result: Pods with app=web and tier=frontend can receive traffic only from Pods with app=api.

Namespace Selector​

Target namespaces:

spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend

IP Block​

Target IP ranges:

spec:
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24
        except:
        - 192.168.1.100/32

Complete Example: Multi-Tier Application​

Architecture​

Network Policy: Frontend​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from: []  # Allow from anywhere (Internet via Ingress)
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: backend
    ports:
    - protocol: TCP
      port: 80

Network Policy: Backend​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: database
    ports:
    - protocol: TCP
      port: 5432

Network Policy: Database​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: backend
    ports:
    - protocol: TCP
      port: 5432
  egress: []  # No outgoing traffic allowed

Ports and Protocols​

Specifying Ports​

spec:
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
    - protocol: UDP
      port: 53

Port Range (CNI-dependent)​

Some CNIs support port ranges:

spec:
  ingress:
  - ports:
    - protocol: TCP
      port: 8000-8999

Useful Commands​

Management​

# Create a Network Policy
kubectl apply -f network-policy.yaml

# View Network Policies
kubectl get networkpolicies
kubectl get netpol

# Details
kubectl describe networkpolicy frontend-policy

# View by namespace
kubectl get netpol -n production

Testing​

# Test connectivity from a Pod
kubectl exec -it test-pod -- curl http://api-service:8080

# View applied rules (CNI-dependent)
# Calico
calicoctl get networkpolicies

Limitations​

1. CNI Support​

Not all CNIs support Network Policies:

  • Support: Calico, Cilium, Weave Net, Antrea
  • Do not support: Flannel (basic)

2. Performance​

Network Policies may impact performance depending on the CNI.

3. Complexity​

Managing many Network Policies can become complex.

Best Practices​

1. Progressive Approach​

Start by isolating critical namespaces, then expand.

2. Documentation​

Document communication rules between services.

3. Testing​

Test Network Policies before applying them in production.

4. Monitoring​

Monitor blocked connections to detect issues.

5. Default Deny​

Use a "deny all" policy by default, then explicitly allow.

Summary​

In this chapter, you learned:

Network Policy: Control of network traffic between Pods
Default behavior: All Pods can communicate
Selectors: Pod, namespace, IP block
Ingress/Egress: Rules for incoming and outgoing traffic
Ports: Specify allowed ports and protocols
Use cases: Network segmentation, multi-tier isolation
Limitations: Requires a compatible CNI
Best practices: Progressive approach, default deny, testing

Next Steps​

Chapter 9.4: Pod Security Standards
Lab 9.3: Advanced Network Policies

Chapter created on: December 2024