Kubernetes Networking - Learning Module

Loading content...

0/273

Network Policies: Zero-Trust Pod Security

The Case for Pod-Level Firewalls

By default, Kubernetes is completely permissive—every Pod can communicate with every other Pod in the cluster, regardless of namespace. This flat network model simplifies initial development but creates significant security risks:

A compromised Pod can probe and attack any service in the cluster
Sensitive workloads (databases, admin APIs) are accessible from all Pods
Lateral movement after a breach is trivially easy
Compliance requirements (PCI-DSS, HIPAA) typically mandate network segmentation

Network Policies are Kubernetes' answer to this problem. They act as Pod-level firewalls, allowing you to define exactly which Pods can communicate with which other Pods, on which ports, from which namespaces.

What You Will Learn

By the end of this page, you will understand Network Policy concepts, syntax, and patterns. You'll learn to implement zero-trust networking, isolate namespaces, protect databases, and debug policy-related connectivity issues.

Network Policy Fundamentals

A Network Policy is a Kubernetes resource that specifies how Pods can communicate with each other and with external endpoints. It uses label selectors to identify groups of Pods and then defines ingress (incoming) and/or egress (outgoing) rules.

Key Concepts

Pod Selector: Which Pods this policy applies to (selected by labels)
Policy Types: Whether the policy restricts ingress, egress, or both
Ingress Rules: Who can send traffic TO the selected Pods
Egress Rules: Where the selected Pods can send traffic TO
Default Deny: By default, if a Pod is selected by any NetworkPolicy, all traffic not explicitly allowed is denied

CNI Plugin Required

Network Policies are not enforced by Kubernetes itself—they require a CNI (Container Network Interface) plugin that supports them. Popular options include Calico, Cilium, Weave Net, and Antrea. Cloud providers vary: GKE and AKS support them natively; EKS requires installing Calico.

The Default Behavior

Without any Network Policies:

All Pods can receive traffic from anywhere (full ingress)
All Pods can send traffic anywhere (full egress)

With a Network Policy selecting a Pod:

The Pod is isolated for the policy type(s) specified
Only traffic matching explicit rules is allowed
Other Pods without Network Policies remain unrestricted

basic-network-policy.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
  namespace: production
spec:
  # Which Pods does this policy apply to?
  podSelector:
    matchLabels:
      app: api-server
  
  # What types of traffic does this policy restrict?
  policyTypes:
  - Ingress   # Controls incoming traffic
  - Egress    # Controls outgoing traffic
  
  # Rules defining allowed incoming traffic
  ingress:
  - from:
    # Allow from Pods with specific labels
    - podSelector:
        matchLabels:
          app: web-frontend
    # Allow from Pods in specific namespace  
    - namespaceSelector:
        matchLabels:
          environment: production
    # Allow from IP blocks (external)
    - ipBlock:
        cidr: 10.0.0.0/8
        except:
        - 10.1.0.0/16  # But not this subnet
    ports:
    - protocol: TCP
      port: 8080
    - protocol: TCP
      port: 9090
  
  # Rules defining allowed outgoing traffic
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  - to:
    # Allow DNS resolution (essential!)
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

Understanding Selectors: The Policy Language

Network Policy selectors are powerful but subtle. Understanding their behavior is essential for writing correct policies.

Selector Types

Selector Types and Behavior
Selector	Matches	Example Use
podSelector	Pods in the SAME namespace	Allow web → api within namespace
namespaceSelector	All Pods in matching namespaces	Allow from any Pod in 'monitoring' ns
podSelector + namespaceSelector	Specific Pods in specific namespaces	Allow prometheus in monitoring ns
ipBlock	External IP ranges	Allow traffic from corporate network

Critical: AND vs OR Logic

The placement of selectors within the YAML structure determines AND vs OR logic:

# OR logic: Two separate array items
- from:
  - podSelector:        # Match A
      matchLabels:
        app: web
  - namespaceSelector:  # OR Match B
      matchLabels:
        name: monitoring

# AND logic: Same array item with both selectors
- from:
  - podSelector:        # Match A AND B
      matchLabels:
        app: prometheus
    namespaceSelector:
      matchLabels:
        name: monitoring

selector-examples.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# Example 1: Allow from specific Pods in SAME namespace (podSelector only)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    # This ONLY allows frontend Pods in the 'production' namespace
 
---
# Example 2: Allow from specific namespace (namespaceSelector only)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-namespace
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
    # This allows ALL Pods in any namespace labeled purpose=monitoring
 
---
# Example 3: Allow specific Pods from specific namespace (AND logic)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-from-monitoring
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    # IMPORTANT: Same array item = AND logic
    - namespaceSelector:
        matchLabels:
          name: monitoring
      podSelector:
        matchLabels:
          app: prometheus
    # This ONLY allows Pods labeled app=prometheus 
    # AND in namespaces labeled name=monitoring
 
---
# Example 4: Multiple sources with OR logic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-multiple-sources
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    # Separate array items = OR logic
    - podSelector:
        matchLabels:
          app: frontend     # Allow frontend in same namespace
    - podSelector:
        matchLabels:
          app: mobile-bff   # OR mobile-bff in same namespace
    - namespaceSelector:
        matchLabels:
          purpose: monitoring  # OR any Pod in monitoring namespaces

Empty Selectors Have Special Meaning

• podSelector: {} matches all Pods in the scope • namespaceSelector: {} matches all namespaces • Combined: namespaceSelector: {} + podSelector: {} matches everything in the cluster • No selectors in ingress/egress means allow from/to nowhere (deny rule)

Default Deny: The Foundation of Zero-Trust

Zero-trust networking starts with denying all traffic by default and then explicitly allowing only necessary communication. This is implemented using Default Deny policies that select all Pods but define no allow rules.

default-deny-policies.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
# Default deny all ingress traffic to all Pods in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}        # Selects ALL Pods in the namespace
  policyTypes:
  - Ingress              # Denies all incoming traffic
  # No ingress rules = deny all ingress
 
---
# Default deny all egress traffic from all Pods in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress               # Denies all outgoing traffic
  # No egress rules = deny all egress
 
---
# Default deny both ingress AND egress (most restrictive)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  # No rules = deny everything
 
---
# IMPORTANT: Allow DNS when denying egress!
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}        # Applies to all Pods
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Don't Forget DNS!

When implementing egress deny policies, you MUST allow DNS traffic to kube-dns/CoreDNS. Without DNS, Pods cannot resolve Service names and most applications will fail. This is one of the most common Network Policy mistakes.

The Zero-Trust Implementation Pattern

Start with Default Deny: Apply deny-all policies to the namespace
Allow DNS: Ensure Pods can resolve internal names
Allow Necessary Traffic: Add specific policies for each service's requirements
Layer by Layer: Build up allowed traffic incrementally
Monitor and Audit: Use tools like Cilium Hubble to visualize traffic flow

Common Network Policy Patterns

Here are battle-tested patterns for common security requirements:

Pattern 1: Database Protection

Databases should only be accessible from application Pods that need them:

database-protection.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-protection
  namespace: production
spec:
  # Apply to database Pods
  podSelector:
    matchLabels:
      app: postgresql
      tier: database
  policyTypes:
  - Ingress
  - Egress
  ingress:
  # Only allow from API servers
  - from:
    - podSelector:
        matchLabels:
          app: api-server
          tier: backend
    ports:
    - protocol: TCP
      port: 5432
  # Allow from backup jobs in ops namespace
  - from:
    - namespaceSelector:
        matchLabels:
          name: ops
      podSelector:
        matchLabels:
          app: backup-agent
    ports:
    - protocol: TCP
      port: 5432
  egress:
  # Only allow DNS (for initial setup/configuration)
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

Pattern 2: Namespace Isolation

Isolate namespaces so tenants/teams cannot access each other:

namespace-isolation.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# Apply this to each namespace that should be isolated
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-isolation
  namespace: team-alpha   # Repeat for each namespace
spec:
  podSelector: {}         # All Pods in namespace
  policyTypes:
  - Ingress
  - Egress
  ingress:
  # Only allow traffic from within same namespace
  - from:
    - podSelector: {}     # Any Pod in THIS namespace
  # Allow from Ingress controllers (external traffic)
  - from:
    - namespaceSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/component: controller
  # Allow from monitoring namespace
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
  egress:
  # Allow to same namespace
  - to:
    - podSelector: {}
  # Allow DNS
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
  # Allow to external (internet) - optional
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8      # Exclude internal cluster IPs
        - 172.16.0.0/12
        - 192.168.0.0/16

Pattern 3: Three-Tier Application Security

Classic web application with frontend, backend, and database tiers:

three-tier-policies.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
# Frontend: Allow from Ingress, allow to Backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: myapp
spec:
  podSelector:
    matchLabels:
      tier: frontend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - podSelector:
        matchLabels:
          tier: backend
    ports:
    - protocol: TCP
      port: 8080
  - to:  # DNS
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
 
---
# Backend: Allow from Frontend, allow to Database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: myapp
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          tier: database
    ports:
    - protocol: TCP
      port: 5432
  - to:  # DNS
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
  - to:  # External APIs
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8
    ports:
    - protocol: TCP
      port: 443
 
---
# Database: Only allow from Backend (most restrictive)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: myapp
spec:
  podSelector:
    matchLabels:
      tier: database
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: backend
    ports:
    - protocol: TCP
      port: 5432
  egress:
  - to:  # DNS only
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

Advanced Egress Control

Egress policies are often neglected but are critical for:

Data Exfiltration Prevention: Stop compromised Pods from sending data to attacker-controlled servers
Compliance: Ensure sensitive data doesn't leave approved boundaries
Cost Control: Prevent unexpected external API calls
Security Posture: Reduce attack surface by limiting outbound connectivity

egress-control.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
# Pattern: Allow only specific external endpoints
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restricted-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: payment-service
  policyTypes:
  - Egress
  egress:
  # Allow internal cluster traffic
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  
  # Allow DNS
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
  
  # Allow specific external payment gateway IPs
  - to:
    - ipBlock:
        cidr: 198.51.100.0/24  # Stripe API servers
    ports:
    - protocol: TCP
      port: 443
  - to:
    - ipBlock:
        cidr: 203.0.113.0/24   # PayPal API servers
    ports:
    - protocol: TCP
      port: 443
 
---
# Pattern: Block egress to metadata service (security hardening)
# The instance metadata service (169.254.169.254) is a common attack vector
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata-service
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  # Allow everything EXCEPT metadata service
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32  # Block cloud metadata service
 
---
# Pattern: Allow egress only to internal cluster
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: internal-only-egress
  namespace: sensitive-data
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  # Allow to all internal cluster IPs only
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8      # Adjust to your cluster CIDR
    - ipBlock:
        cidr: 172.16.0.0/12
  # Explicitly allow DNS
  - to:
    ports:
    - protocol: UDP
      port: 53

The Metadata Service Attack Vector

Cloud instance metadata services (169.254.169.254) expose sensitive credentials and information. Attackers who compromise a Pod can query this endpoint to escalate privileges. Always consider blocking this in production environments.

Policy Ordering and Precedence

Understanding how multiple Network Policies interact is essential for complex environments.

Key Rules

Policies are Additive: If multiple policies select a Pod, the Pod receives the UNION of all allowed traffic
No Explicit Deny: You cannot create a rule that denies traffic—only rules that allow it. Denial comes from isolation (selecting the Pod) without a matching allow rule
No Order Dependency: Unlike traditional firewalls, Network Policies don't have priority or order
Namespace Scoped: Policies only affect Pods in their own namespace

policy-combination.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# Policy A: Allow from frontend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
 
---
# Policy B: Allow from monitoring
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9090
 
# RESULT: the 'api' Pods allow:
# - TCP 8080 from frontend Pods in production namespace (from Policy A)
# - TCP 9090 from any Pod in namespaces labeled monitoring (from Policy B)
# All other ingress traffic is denied (Pods are isolated by having policies)

Policy Combination Scenarios
Scenario	Result	Explanation
No policies select a Pod	All traffic allowed	Pod is not isolated
One policy selects, no rules	All traffic of that type denied	Isolation without allows
Multiple policies select	Union of all rules	Additive behavior
Policy allows port 80, another allows port 443	Both ports allowed	Rules combined
Two policies, one for ingress, one for egress	Both types restricted per their rules	Independent policy types

Common Misconception

There's no way to create a 'higher priority deny rule' that overrides an allow. If you need to prevent traffic that another policy allows, you must either remove/modify that policy or redesign your label structure to prevent the unwanted allow rule from matching.

CNI-Specific Advanced Features

The standard Kubernetes NetworkPolicy API covers common use cases, but CNI plugins like Calico and Cilium offer extended capabilities through custom resources.

Calico: GlobalNetworkPolicy and HostEndpoints

Calico extends Network Policies with cluster-wide policies and host-level controls:

calico-policies.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# Calico GlobalNetworkPolicy - applies across all namespaces
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-external-egress
spec:
  # Apply to all Pods in all namespaces
  selector: all()
  types:
  - Egress
  egress:
  # Allow internal cluster traffic
  - action: Allow
    destination:
      nets:
      - 10.0.0.0/8
  # Allow DNS
  - action: Allow
    protocol: UDP
    destination:
      ports:
      - 53
  # Deny everything else (explicit deny available in Calico)
  - action: Deny
    destination:
      notNets:
      - 10.0.0.0/8
 
---
# Calico supports application layer (L7) policies
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: l7-policy
  namespace: production
spec:
  selector: app == 'api'
  ingress:
  - action: Allow
    http:
      methods: ["GET", "POST"]
      paths:
      - exact: /api/health
      - prefix: /api/v1/
  - action: Deny

Cilium: Advanced eBPF-Based Policies

Cilium uses eBPF for high-performance, feature-rich network policies:

cilium-policies.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# Cilium L7 HTTP-aware policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-api-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/public/.*"
        - method: "POST"
          path: "/api/v1/.*"
          headers:
          - 'Content-Type: application/json'
 
---
# Cilium DNS-aware egress policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: dns-aware-egress
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      rules:
        dns:
        - matchPattern: "*"
  # Allow egress by DNS name (resolved automatically)
  - toFQDNs:
    - matchName: "api.stripe.com"
    - matchPattern: "*.amazonaws.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

CNI Feature Comparison
Feature	Standard K8s	Calico	Cilium
L3/L4 Policies	✅	✅	✅
Namespace Selectors	✅	✅	✅
Global/Cluster Policies	❌	✅	✅
L7 HTTP Policies	❌	✅ (Enterprise)	✅
DNS-Based Egress	❌	Limited	✅
Explicit Deny Rules	❌	✅	✅
Host-Level Policies	❌	✅	✅
Policy Visualization	❌	✅	✅ (Hubble)

Troubleshooting Network Policies

Network Policy issues can be frustrating to debug because blocked traffic often fails silently. Here's a systematic approach:

troubleshoot-netpol.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# Step 1: Verify CNI supports Network Policies
kubectl get pods -n kube-system | grep -E 'calico|cilium|weave'
# If using EKS without Calico, policies won't work!
 
# Step 2: List all policies affecting a namespace
kubectl get networkpolicies -n production
 
# Step 3: Describe a specific policy
kubectl describe networkpolicy my-policy -n production
 
# Step 4: Check what policies select a specific Pod
# Get Pod labels first
kubectl get pod my-pod -n production --show-labels
 
# Then find policies that match those labels
kubectl get networkpolicies -n production -o yaml | \
  grep -B20 "app: my-app"  # Search for matching selectors
 
# Step 5: Test connectivity from source to destination
# Start a debug pod
kubectl run -it --rm netshoot --image=nicolaka/netshoot -n production -- bash
 
# Inside debug pod:
# nc -zv <service-name> <port>    # Test TCP connectivity
# curl -v <service-name>:<port>   # Test HTTP
# nslookup <service-name>         # Test DNS
 
# Step 6: Use network policy dry-run tools
# For Calico:
calicoctl get networkpolicies -n production -o yaml
calicoctl node status
 
# For Cilium:
cilium policy get -n production
cilium endpoint list
hubble observe --namespace production  # Live traffic flow
 
# Step 7: Temporarily disable policies to isolate issue
# Create allow-all policy (testing only!)
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: debug-allow-all
  namespace: production
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress
EOF
 
# Don't forget to delete after testing!
kubectl delete networkpolicy debug-allow-all -n production

Common Network Policy Issues
Symptom	Cause	Solution
All traffic blocked	Default deny without allow rules	Add specific ingress/egress rules
DNS not working	Egress policy blocking DNS	Add rule allowing UDP 53 to kube-dns
Policies not enforcing	CNI doesn't support policies	Install Calico/Cilium or enable provider support
Some Pods work, others don't	Label mismatch in selectors	Verify Pod labels match policy selectors
Cross-namespace blocked	Missing namespaceSelector	Add namespaceSelector to from/to rules
Health checks failing	Policy blocking kubelet	Allow from node CIDR or kubelet IPs
Service discovery broken	kubectl exec/port-forward blocked	Allow API server communication

Visualization Tools

Use visualization tools to understand traffic flow: • Cilium Hubble: Real-time network flow visibility • Calico Enterprise: Policy visualization dashboard • Network Policy Viewer: Open-source tool for visualizing policies • Kube-network-policies: CLI tool to preview policy effects

Summary: Network Policies

We've comprehensively covered Kubernetes Network Policies. Let's consolidate the key takeaways:

Key Takeaways

•Default Kubernetes networking is fully open — any Pod can reach any other Pod. Network Policies implement segmentation.
•Policies require a supporting CNI — Calico, Cilium, or cloud provider support is mandatory for enforcement.
•Zero-trust starts with default deny — select all Pods, define no rules, then explicitly allow required traffic.
•Selector logic is critical — understand AND vs OR behavior to write correct policies.
•Always allow DNS when implementing egress restrictions, or applications will fail.
•Policies are additive — multiple policies combine via union; there's no explicit deny in standard API.
•Extended features via CNI CRDs — Calico and Cilium offer L7 policies, global policies, and DNS-aware egress.

What's Next:

With Network Policies securing Pod communication, we need reliable service discovery within the cluster. In the next page, we'll explore DNS in Kubernetes—how CoreDNS works, DNS records for Services, and debugging DNS issues.

Page Complete

You now understand Network Policies—from fundamentals through advanced patterns. You can implement zero-trust networking, protect databases, isolate namespaces, and troubleshoot policy issues. Next, we'll explore the DNS system that enables service discovery in Kubernetes.