Network Policies & Segmentation - Networking Basics

Network policies and segmentation are critical for security, compliance, and network organization in modern infrastructure.

Why Network Segmentation?

Problem: Flat network with everything connected:

If one device is compromised → Attacker can reach everything

Solution: Divide network into segments, control traffic between them:

Production segment ← → Firewall → Development segment
(isolated)                      (isolated)
                               ↓ Controlled

Network Segmentation Approaches

1. Physical Segmentation Different physical networks:

Network A: 192.168.1.0/24 → Separate switch/cables
Network B: 10.0.0.0/24 → Separate switch/cables
Connected via router with rules

Pros: Very secure Cons: Expensive, inflexible, hard to manage

2. VLAN (Virtual LAN) Segmentation Virtual networks on same physical hardware:

Physical Switch
├── VLAN 10: 192.168.1.0/24 (Prod)
├── VLAN 20: 192.168.2.0/24 (Dev)
├── VLAN 30: 192.168.3.0/24 (Guest)
└── Trunk: Inter-VLAN router

Pros: Flexible, cost-effective Cons: Requires VLAN-capable switches

3. Software Segmentation Firewall rules in software:

Same network, but firewall enforces boundaries
192.168.1.0/24 (whole subnet)

Rule: 192.168.1.0-50 (Prod) → 192.168.1.51-100 (Dev)
Action: DENY (isolated despite same subnet)

Pros: Very flexible Cons: Requires understanding traffic patterns

VLAN Basics

What is a VLAN? Logical grouping of devices regardless of physical location:

Building 1, 2nd Floor, Port 5  → VLAN 10 (Prod)
Building 2, 1st Floor, Port 12 → VLAN 10 (Prod)
Building 3, Basement, Port 8   → VLAN 10 (Prod)

All three ports in same VLAN, physically distant
Can communicate as if on same physical network

VLAN Tagging

Frames include VLAN ID (802.1Q):

Frame format:
┌─────────────────────────┐
│ Destination MAC         │
│ Source MAC              │
│ VLAN Tag (4 bytes)      │ ← Contains VLAN ID (VID)
│ Protocol                │
│ Payload                 │
└─────────────────────────┘

VID: 0-4095 (12 bits)
VID 1: Default
VID 0: Priority only (management)

Access vs Trunk Ports

Port Type	VLANs	Use
Access	Single	End devices (PC, server)
Trunk	Multiple	Switch-to-switch, router uplinks

Example:

PC1 → Port 1 (Access, VLAN 10)
PC2 → Port 2 (Access, VLAN 10)
PC3 → Port 3 (Access, VLAN 20)

Port 24 (Trunk) connects to another switch
All VLAN traffic multiplexed on trunk

Kubernetes Network Policies

Modern container platforms use network policies instead of VLANs:

Network Policy Definition:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: production
spec:
  podSelector: {}  # Applies to all pods
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: production
    ports:
    - protocol: TCP
      port: 3306

Meaning:

Pods in production namespace can only receive traffic from other production pods on port 8080
Pods can only send to production namespace on port 3306 (database)
All other traffic blocked

Network Policy Strategies

1. Default Deny (Whitelist Approach)

# Block everything by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}  # All pods
  policyTypes:
  - Ingress
  - Egress
  # No rules means: DENY ALL

Then explicitly allow needed traffic:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 80

Pros: Very secure Cons: Must carefully define all policies

2. Namespace Isolation

# Prevent cross-namespace traffic by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: namespace-isolation
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: production  # Only from same namespace

3. Tier-Based Policy

# Frontend can reach backend on port 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 8080

Network Segmentation Best Practices

DMZ (Demilitarized Zone)

Internet
  ↓
┌─────────────────┐
│ DMZ Firewall    │ ← Internet-facing services
├─────────────────┤
│ Internal FW     │ ← Protects internal network
└─────────────────┘
  ↓ (if authorized)
Internal Network (Databases, App servers)

Three-Tier Segmentation

┌─────────────────────┐
│ Web Tier            │ (Exposed to internet)
│ 192.168.1.0/24      │
├─────────────────────┤
│ Application Tier    │ (Internal API)
│ 192.168.2.0/24      │
├─────────────────────┤
│ Data Tier           │ (Databases)
│ 192.168.3.0/24      │
└─────────────────────┘

Firewall rules:
- Internet → Web (port 80, 443)
- Web → App (port 8080)
- App → Data (port 3306, 5432)
- All other: DENY

Implementation Considerations

Traffic Flow Analysis Before implementing policies:

Map all services and dependencies
Document required connections
Test in non-production first

Troubleshooting Blocked Traffic

# Check if policy applying
kubectl get networkpolicy -A
 
# Describe specific policy
kubectl describe networkpolicy -n production allow-web
 
# Test connectivity (from pod)
kubectl exec -it pod-name -- sh
nc -zv destination-ip port
 
# Check CNI plugin logs
# (varies by CNI: Calico, Weave, etc.)

CNI Plugin Support Not all CNI plugins support NetworkPolicy:

CNI	Support
Calico	Yes
Flannel	Limited
Weave	Yes
Cilium	Yes (+ advanced)
Amazon VPC CNI	Partial

Advanced Segmentation

Zero Trust Network Assume no network is trusted:

Verify every connection
Least privilege access
Encrypt everything
Monitor all traffic

Microsegmentation Application-level isolation:

Service A ↔ [Auth Check] ↔ Service B
      ↓
   Verify identity
   Verify authorization
   Verify encryption
   Log access

Monitoring Network Policies

View active policies:

# Show all policies
kubectl get networkpolicy -A
 
# Detailed view
kubectl describe networkpolicy -n production allow-web
 
# Show policy in YAML
kubectl get networkpolicy -n production allow-web -o yaml

Network Policy Violations

# CNI plugin logs (example: Calico)
kubectl logs -n calico-system daemonset/calico-node
 
# Denied connections visible in firewall logs
# iptables logs: /var/log/syslog or journalctl
journalctl | grep "DROP"

Common Patterns

Pattern 1: Frontend ↔ Backend

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-backend
spec:
  podSelector:
    matchLabels:
      tier: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend

Pattern 2: Allow Prometheus Scraping

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus
spec:
  podSelector: {}  # All pods
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9090  # Prometheus metrics port

Pattern 3: DNS Access

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53  # DNS

Key Concepts

Segmentation divides network into isolated zones
VLANs provide logical segmentation on physical infrastructure
Network Policies provide application-level segmentation in Kubernetes
Default Deny (whitelist) more secure than default allow
Tier-based policies align with application architecture
DMZ pattern protects internal resources
Zero Trust assumes no network is trusted
Test policies thoroughly before production