What Are Network Segmentation Strategies in Kubernetes?

Detailed Answer

Network segmentation divides a Kubernetes cluster into security zones with controlled communication between them. This limits the damage an attacker can do after compromising a single workload — instead of accessing the entire cluster, they are confined to one segment.

Strategy 1: Namespace-Based Segmentation

The most common approach — use namespaces as security boundaries with Network Policies:

# Create isolated namespaces
apiVersion: v1
kind: Namespace
metadata:
  name: frontend
  labels:
    zone: public
    team: frontend
---
apiVersion: v1
kind: Namespace
metadata:
  name: backend
  labels:
    zone: internal
    team: backend
---
apiVersion: v1
kind: Namespace
metadata:
  name: data
  labels:
    zone: restricted
    team: data

Apply segmentation rules:

# Data zone: only accessible from backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: data-zone-policy
  namespace: data
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              zone: internal
      ports:
        - protocol: TCP
          port: 5432
  egress:
    - to:
        - podSelector: {}
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

Strategy 2: Tier-Based Segmentation

Organize workloads into security tiers:

┌─────────────────────────────────────────┐
│              INTERNET                    │
└──────────────┬──────────────────────────┘
               │
┌──────────────▼──────────────────────────┐
│  DMZ Tier: Ingress controllers, WAF      │
│  (namespace: dmz)                        │
└──────────────┬──────────────────────────┘
               │ Only HTTPS on 443
┌──────────────▼──────────────────────────┐
│  Application Tier: APIs, frontends       │
│  (namespace: app)                        │
└──────────────┬──────────────────────────┘
               │ Only DB ports
┌──────────────▼──────────────────────────┐
│  Data Tier: Databases, caches            │
│  (namespace: data)                       │
└─────────────────────────────────────────┘

# Application tier can only reach data tier on specific ports
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-tier-egress
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              tier: data
      ports:
        - protocol: TCP
          port: 5432        # PostgreSQL
        - protocol: TCP
          port: 6379        # Redis
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
---
# Data tier cannot reach the internet
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: data-tier-deny-external
  namespace: data
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector: {}             # Same namespace only
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

Strategy 3: Node-Level Segmentation

Use dedicated node pools for different security zones:

# Sensitive workloads on dedicated nodes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
  namespace: pci
spec:
  template:
    spec:
      nodeSelector:
        security-zone: pci
      tolerations:
        - key: "security-zone"
          value: "pci"
          effect: "NoSchedule"
      containers:
        - name: processor
          image: myapp/payment:v3
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"

Node-level segmentation benefits:

• Physical network isolation between node pools
• Different security group/firewall rules per pool
• Prevents co-located workloads from accessing local resources
• Meets compliance requirements for physical separation

Strategy 4: Multi-Cluster Segmentation

The strongest isolation — use separate clusters for different security domains:

Production Cluster      Staging Cluster       Management Cluster
┌────────────────┐     ┌────────────────┐     ┌────────────────┐
│ Customer data  │     │ Test data      │     │ Monitoring     │
│ Payment APIs   │     │ QA workloads   │     │ CI/CD          │
│ User services  │     │ Dev environments│     │ Logging        │
└────────────────┘     └────────────────┘     └────────────────┘

Use multi-cluster for:

• PCI-DSS, HIPAA, or SOC2 compliance
• Separation between production and non-production
• Blast radius containment at the infrastructure level
• Different trust boundaries (customer-facing vs internal)

Strategy 5: Service Mesh Micro-Segmentation

Service meshes provide the most granular segmentation using workload identity:

# Istio: Allow only specific HTTP methods and paths
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-access
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-api
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/checkout-service"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/charge"]

Choosing a Strategy

| Factor | Namespace | Tier-Based | Node-Level | Multi-Cluster | |---|---|---|---|---| | Implementation effort | Low | Medium | Medium | High | | Isolation strength | Medium | Medium | High | Highest | | Operational overhead | Low | Low | Medium | High | | Compliance suitable | Basic | Moderate | Good | Best | | Resource efficiency | High | High | Lower | Lowest |

Best Practices

1. Start with default-deny: Apply to every namespace before adding allow rules
2. Segment by sensitivity: Put databases and secrets in restricted zones
3. Minimize cross-zone communication: Each allowed path is an attack surface
4. Log cross-zone traffic: Monitor for anomalous access patterns
5. Test segmentation regularly: Use security scanning tools to verify isolation
6. Document the architecture: Maintain a network flow diagram showing all allowed paths