Kubernetes Network Security

Network Policies Zero-Trust mTLS Firewall Egress Filtering

A comprehensive guide to Kubernetes network security covering network policies, zero-trust networking, mTLS, firewall, egress filtering, and practical implementation strategies for securing cluster communication.

Network Policies Zero-Trust mTLS Egress Filtering

The Importance of Network Security

Network security is a critical component of Kubernetes security. Without proper network controls, an attacker who compromises one pod can potentially access other pods and services within the cluster. Network security in Kubernetes includes:

Network Policies: Control pod-to-pod communication
Zero-Trust Networking: Never trust, always verify
mTLS: Encrypt and authenticate service-to-service communication
Egress Filtering: Control outbound traffic from the cluster
Service Mesh: Advanced networking with mTLS and traffic management

Zero-Trust Principle: In a zero-trust network, no entity is trusted by default. Every request must be authenticated, authorized, and encrypted. Service meshes and network policies are key enablers of zero-trust in Kubernetes.

Network Policies: Pod-to-Pod Segmentation

Network Policies are Kubernetes resources that define how pods can communicate with each other and with other network endpoints. They provide network segmentation and enforce the principle of least privilege at the network level.

                # Default Deny All Ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}  # Applies to all pods
  policyTypes:
  - Ingress

# Default Deny All Egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

# Allow Ingress from Same Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-namespace-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector: {}  # All pods in same namespace
    ports:
    - port: 8080
  policyTypes:
  - Ingress

# Allow Ingress from Specific Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-monitoring
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - port: 8080
  policyTypes:
  - Ingress

# Allow Ingress from Specific Pod with Label
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080
      protocol: TCP
  policyTypes:
  - Ingress

# Allow Egress to External Database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-db
spec:
  podSelector:
    matchLabels:
      app: my-app
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - port: 5432
      protocol: TCP
  policyTypes:
  - Egress

# Combined Ingress + Egress Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: combined-policy
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    ports:
    - port: 8080
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - port: 5432
  policyTypes:
  - Ingress
  - Egress
            

Network Policy Requirements: Network Policies require a CNI plugin that supports them (Calico, Cilium, Weave, Antrea). Flannel does not support Network Policy by default. Always test policies in a non-production environment first.

Zero-Trust Networking in Kubernetes

Zero-trust networking assumes that no network is inherently safe. Every request must be authenticated, authorized, and encrypted. In Kubernetes, zero-trust is achieved through a combination of:

mTLS Authentication

Mutual TLS

Every service has a certificate and must authenticate itself before communicating. Service meshes (Istio, Linkerd) provide automatic mTLS.

Identity verification

Authorization Policies

Fine-grained access control

Service meshes allow you to define which services can talk to which other services based on identities, not just IP addresses.

Access control

Network Segmentation

Micro-segmentation

Network Policies and service meshes provide micro-segmentation, isolating workloads and limiting lateral movement.

Lateral movement prevention

Observability

Flow logs and metrics

Zero-trust requires visibility. Service meshes provide flow logs, metrics, and distributed tracing for all service-to-service communication.

Audit and monitoring

                # Istio Authorization Policy (Zero-Trust)
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: zero-trust-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend-sa"]
        namespaces: ["default"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]
  - from:
    - source:
        principals: ["cluster.local/ns/monitoring/sa/prometheus-sa"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/metrics"]

# Linkerd Authorization Policy
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: backend-server
  namespace: default
  labels:
    app: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  port: 8080
  proxyProtocol: HTTP/1.1

---
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: backend-auth
  namespace: default
spec:
  server:
    name: backend-server
  client:
    meshTLS:
      identities:
      - frontend.default.serviceaccount.identity.linkerd.cluster.local
      - prometheus.monitoring.serviceaccount.identity.linkerd.cluster.local
            

mTLS: Mutual TLS for Service Communication

Mutual TLS (mTLS) is the foundation of secure service-to-service communication. It provides both encryption and authentication, ensuring that only authorized services can communicate.

                # Istio mTLS Configuration
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # STRICT, PERMISSIVE, DISABLE

# mTLS with DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: backend-dr
  namespace: default
spec:
  host: backend-service
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # Enables mTLS

# Linkerd mTLS (enabled by default)
# Check mTLS status
linkerd viz authz deploy/backend

# Certificate Management with cert-manager
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: istio-system
spec:
  ca:
    secretName: istio-ca-secret

# Service Mesh mTLS Flow
# 1. Service A requests Service B
# 2. Sidecar proxy (Envoy/Linkerd) intercepts request
# 3. Proxy establishes mTLS connection using certificates
# 4. Both proxies verify each other's certificates
# 5. Encrypted communication continues
            

mTLS Best Practices:

Enable mTLS for all service-to-service communication
Use STRICT mode for production (enforce mTLS)
Automate certificate management with Istio/Linkerd
Monitor mTLS failures and certificate expiration
Use service meshes for automatic mTLS management

Egress Filtering: Controlling Outbound Traffic

Egress filtering controls what external resources pods can access. This is critical for preventing data exfiltration and limiting attack surfaces.

                # NetworkPolicy for Egress Control
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-egress
spec:
  podSelector:
    matchLabels:
      app: my-app
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24  # Internal network
    ports:
    - port: 5432
      protocol: TCP
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0   # Allow all external
        except:
        - 10.0.0.0/8     # Except internal
        - 192.168.0.0/16
        - 172.16.0.0/12
    ports:
    - port: 443
      protocol: TCP
  policyTypes:
  - Egress

# Istio Egress Gateway
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: egress-rule
  namespace: istio-system
spec:
  host: egress-gateway.istio-system.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

# ServiceEntry for external services
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-db
spec:
  hosts:
  - db.example.com
  ports:
  - number: 5432
    name: tcp
    protocol: TCP
  resolution: DNS
  location: MESH_EXTERNAL

# Deny all egress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

# Allow DNS resolution
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 10.96.0.0/12  # Cluster DNS range
    ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
  policyTypes:
  - Egress
            

Egress Considerations:

Deny all egress by default, then allow specific destinations
Always allow DNS resolution (port 53) for service discovery
Use IP blocks with except to exclude internal networks
Test egress policies thoroughly before enforcing
Monitor egress traffic for anomalies

Service Mesh for Advanced Network Security

Service meshes (Istio, Linkerd) provide advanced network security features beyond what's possible with Network Policies alone.

Automatic mTLS

Service meshes automatically manage certificates and enforce mTLS without application changes.

Encryption & authentication

Identity-Based Security

Policies are based on service identities (not IP addresses), enabling zero-trust networking.

Fine-grained authorization

Observability

Flow logs, metrics, and traces provide visibility into all network traffic.

Monitoring & audit

Security Policies

Authorization policies, rate limiting, and circuit breaking at the network level.

Protection & resilience

                # Istio Authorization with mTLS
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: secure-backend
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend-sa"]
    to:
    - operation:
        methods: ["GET", "POST"]
    when:
    - key: request.headers[Authorization]
      values: ["Bearer *"]

# Rate Limiting (EnvoyFilter)
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: rate-limit
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: backend
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          stat_prefix: http_local_rate_limiter
          token_bucket:
            max_tokens: 10
            tokens_per_fill: 1
            fill_interval: 1s
            

Network Security Checklist

Network Policies

✓ Default deny all ingress/egress

✓ Allow only necessary communication

✓ Use namespace isolation

✓ Implement micro-segmentation

Encryption

✓ Enable mTLS for all services

✓ Use service mesh for automation

✓ Encrypt data in transit

✓ Monitor certificate expiration

Egress Control

✓ Deny all egress by default

✓ Allow specific external services

✓ Use egress gateways

✓ Monitor egress traffic

Observability

✓ Monitor network traffic flows

✓ Alert on policy violations

✓ Enable flow logs

✓ Regular security audits

Implementation Order:

Start with default deny all policies
Gradually allow specific traffic based on application requirements
Enable mTLS with service mesh
Implement egress controls
Set up observability and alerting
Regularly audit and refine policies

Frequently Asked Questions

What is the difference between NetworkPolicy and Service Mesh security?

NetworkPolicy controls pod-to-pod communication at the IP/port level. Service mesh security (Istio, Linkerd) provides identity-based security, mTLS, and advanced features like rate limiting, circuit breaking, and distributed tracing. Service mesh complements NetworkPolicy.

What is zero-trust networking in Kubernetes?

Zero-trust networking means no entity is trusted by default. Every request must be authenticated, authorized, and encrypted. In Kubernetes, zero-trust is achieved through mTLS, Network Policies, and service meshes.

How does mTLS work in Kubernetes?

mTLS (Mutual TLS) provides two-way authentication and encryption. Each service gets a certificate from a certificate authority. When services communicate, they verify each other's certificates and establish an encrypted connection. Service meshes automate this process.

What is egress filtering and why is it important?

Egress filtering controls outbound traffic from pods to external networks. It's important for preventing data exfiltration, limiting attack surfaces, and enforcing security policies. Start with deny all egress and allow specific destinations.

Can I use NetworkPolicy without a service mesh?

Yes! NetworkPolicy is a Kubernetes native resource and works without a service mesh. However, you need a CNI that supports NetworkPolicy (Calico, Cilium, Weave, Antrea). NetworkPolicy provides basic pod-to-pod segmentation.

What are the best practices for NetworkPolicy?

Best practices: default deny all ingress and egress, allow only necessary communication, use namespace isolation, implement micro-segmentation, test policies in staging, and monitor policy violations.

How do I monitor network security in Kubernetes?

Use service mesh observability (flow logs, metrics, traces), NetworkPolicy audit logs, and tools like Cilium's Hubble. Set up alerts for policy violations, unusual traffic patterns, and mTLS failures.

What is the performance impact of network security features?

NetworkPolicy has minimal overhead (iptables/eBPF rules). Service mesh mTLS adds some latency (typically 1-5ms) but provides significant security benefits. eBPF-based solutions (Cilium, Linkerd) offer better performance.

Previous: OPA & Gatekeeper Next: Kubernetes Monitoring

Network security is essential for protecting Kubernetes clusters. Implement defense-in-depth with Network Policies, mTLS, egress filtering, and zero-trust principles to secure your cluster communication.