Kubernetes DDoS Protection | Stop Attacks Now

L3/L4 (network/transport layer) floods: SYN floods, UDP floods, volumetric attacks overwhelming bandwidth. Defense: cloud provider absorbs (AWS Shield, Cloudflare), network policies block source IPs, rate limit connections. L7 (application layer) targets: HTTP floods, API abuse, slowloris attacks exhausting pod resources. Defense requires app-aware tools: ingress rate limiting, WAF rules, pod autoscaling, request validation. Impact difference: L3/L4 attack = 100Gbps traffic crashes network (cloud provider problem), L7 attack = 10,000 req/sec crashes pods (your problem). Real example: 50Gbps SYN flood blocks all traffic → use cloud DDoS protection. 5000 req/sec to expensive API endpoint → use ingress nginx rate limiting (limit-req-zone). Kubernetes exposure: LoadBalancer services vulnerable to L3/L4, ingress controllers need L7 protection. Most attacks now L7 (70%) because L3/L4 easily mitigated by cloud.

Three layers: ingress controller, application middleware, network policies. Ingress (nginx example): add annotations to Ingress resource—nginx.ingress.kubernetes.io/limit-rps: "10" (10 req/sec per IP), limit-connections: "5" (5 concurrent connections). Traefik uses RateLimit middleware with average/burst config. Effective config: 10-50 req/sec for APIs, 100-200 for static content, 1-5 for expensive operations (login, search). Application layer: use middleware (Express rate-limiter, Django throttling) for fine-grained control—rate limit by user ID not just IP (handles proxies). Network policies: Cilium/Calico limit connections to pods—prevent pod-to-pod floods. Test before production: use hey or wrk load testing tools, verify rate limits trigger correctly. Common mistake: rate limiting by pod instead of globally—use Redis for shared state across pods. Example: nginx limit-req-zone $binary_remote_addr zone=api:10m rate=10r/s.

Horizontal Pod Autoscaling (HPA) helps against L7 attacks but has limits—don't rely on it alone. Benefits: legitimate traffic spikes handled (Black Friday sales), gradual attacks absorbed (scale from 3 → 30 pods). Limits: scaling takes 30-90 seconds (attack overwhelms before scaling), costs spike during attack ($100/month → $5000/month if uncapped), attackers can exhaust your quota/budget. Smart approach: combine HPA with rate limiting—rate limits stop attack traffic, HPA handles legitimate overflow. Configure: kubectl autoscale deployment api --cpu-percent=70 --min=3 --max=20 (cap max to control costs). Set resource limits: requests/limits prevent single pod consuming all resources. Cost protection: set PodDisruptionBudget and cluster autoscaler max nodes (cap at budget-safe number). Real scenario: e-commerce site scales 10 → 100 pods during attack, $500 AWS bill → use Cloudflare + rate limiting instead, stay at 10 pods.

Immediate indicators: sudden CPU/memory spike (80%+ across all pods), ingress controller logs show single IPs hitting 100+ req/sec, pod crash loops (OOMKilled), LoadBalancer connection exhaustion. Monitoring alerts: Prometheus metrics—increase in nginx_ingress_controller_requests (10x normal), kube_pod_container_status_restarts_total spikes, high P95/P99 latency (500ms → 5000ms). Cloud provider signs: AWS Shield notifications, Cloudflare "I'm Under Attack" mode auto-triggers, sudden bandwidth spike in CloudWatch (1Gbps → 50Gbps). User reports: customers can't access site, timeout errors, slow page loads. Log patterns: kubectl logs shows repeated requests from limited IP ranges, identical User-Agents, sequential request patterns. Quick check: kubectl top nodes shows 95%+ CPU on all nodes, kubectl get hpa shows autoscaler maxed out. Distinguish from legit traffic: DDoS has uniform request patterns, legitimate has varied user behavior.