SPARK: Secure Predictive Autoscaling for Robust Kubernetes

1. Problem Statement

Traditional Kubernetes autoscaling mechanisms, such as the native Horizontal Pod Autoscaler (HPA) and reactive solutions like KEDA, rely on threshold-based metrics (e.g., CPU usage or request rates). These approaches suffer from two critical limitations:

• Reactive Latency: They fail to react quickly enough to sudden traffic spikes (flash crowds), leading to increased timeout errors and service degradation before new pods are provisioned.
• Security Vulnerability: They cannot distinguish between legitimate traffic surges and malicious attacks (e.g., DDoS or Denial-of-Wallet attacks). Consequently, autoscalers often scale up in response to attack traffic, wasting resources, increasing costs, and potentially exacerbating the denial of service.

Existing predictive solutions (like the proprietary PredictKube) improve reaction times but lack granular traffic differentiation, leaving systems vulnerable to malicious scaling triggers.

2. Methodology: The SPARK Architecture

The authors propose SPARK (Secure Predictive Autoscaling for Robust Kubernetes), an open-source toolchain that integrates predictive machine learning with eBPF-based security enforcement. The system operates across three distinct tiers:

Tier 1: XDP Pre-Filter (Network Edge)

• Technology: Uses eXpress Data Path (XDP) programs running in the kernel.
• Function: Maintains blocklists and rate-limit maps. It drops volumetric attacks (e.g., SYN floods) before they reach the OS network stack.
• Security Benefit: Prevents malicious packets from generating metrics that would falsely trigger autoscaling events. It works in conjunction with the Kong Gateway for ingress management.

Tier 2: Cilium L7 Policies (CNI Layer)

• Technology: Leverages Cilium (an eBPF-based Container Network Interface) and Hubble (observability platform).
• Function: Enforces identity-based Layer 7 policies, limiting HTTP rates per source identity to prevent a single compromised node from flooding the backend.
• Legitimacy Scoring: Hubble captures Layer 7 flow data to calculate a Legitimacy Score:
  $$\text{Legitimacy Score} = \frac{\sum \text{HTTP 2xx}}{\sum \text{HTTP Total}}$$
  Traffic is considered legitimate if the score $\ge 0.85$. This metric is crucial for distinguishing DoS attacks (high error rates) from flash crowds.

Tier 3: Security-Aware Controller (Meta-Scaler)

• Technology: A custom controller integrating KEDA, Prometheus, PredictKube (or an open-source LSTM model), and Hubble.
• Function: Acts as a "meta-scaler" that reconciles three data streams:
  1. Reactive Metrics: Real-time data from Prometheus.
  2. Proactive Forecasts: Predictions from ML models (PredictKube or LSTM).
  3. Legitimacy Scores: Real-time validation from Hubble.
• Logic: If the Legitimacy Score drops below 0.85 (indicating an attack), the controller caps scaling regardless of the demand forecast, preventing resource exhaustion.

Network Integration

When scaling occurs, Cilium updates eBPF maps in the kernel to instantly wire new pods into the data plane. This eliminates the latency associated with iptables convergence, ensuring immediate connectivity for new pods.

3. Key Contributions

• Integrated Toolchain: An open-source solution combining KEDA, Cilium, and eBPF to create a traffic-aware autoscaling ecosystem.
• Security-Aware Scaling: A novel mechanism that fuses predictive demand forecasting with real-time traffic legitimacy verification to prevent scaling during attacks.
• Kernel-Level Enforcement: Utilization of XDP and Cilium to enforce security policies and update network routing at the kernel level, providing immediate convergence and isolation for new pods.
• Denial-of-Wallet (DoW) Mitigation: Specifically addresses the economic impact of attacks by preventing the system from scaling up for malicious traffic.

4. Experimental Results

The system was evaluated on an Amazon EKS cluster (Kubernetes v1.27) using the Vegeta load testing tool under two scenarios:

Scenario A: Flash Crowd (Legitimate Surge)

• Setup: Traffic ramped from 0 to 500 RPS over 30 seconds.
• Comparison: Reactive Scaling (KEDA/Prometheus) vs. Predictive Scaling (KEDA/PredictKube).
• Results:
  • Timeout Rate: Reduced by 32.6% (from 18.7% to 12.6%).
  • Scale Lag: Reduced by 54.8% (from 42s to 19s).
  • Pod Count: Predictive scaling utilized slightly more pods (8.1 vs 7.2) to proactively handle load, resulting in higher stability.

Scenario B: Mixed Traffic (Legitimate + DDoS)

• Setup: 80% legitimate traffic (HTTP 200) mixed with 20% malicious traffic (HTTP 4xx/5xx).
• Reactive Behavior: Treated all traffic as legitimate, aggressively scaling to 15 pods (wasting resources).
• SPARK Behavior:
  • Detected a Legitimacy Score < 0.85.
  • Capped scaling at 8 pods.
  • XDP Layer: Dropped 92% of malicious traffic at the ingress before it could impact the application layer.

5. Significance and Future Work

Significance:
SPARK demonstrates that integrating predictive analytics with kernel-level security enforcement creates a robust defense against both service unavailability and resource exhaustion. It solves the "blind spot" in current autoscalers where they cannot differentiate between a viral marketing event and a DDoS attack.

Future Work:
The authors plan to:

1. Fully implement and evaluate their own open-source LSTM-based scaler to replace the proprietary PredictKube dependency.
2. Enhance the controller with explainability features to help operators understand scaling decisions.
3. Develop adaptive thresholds for the Legitimacy Score based on learned baseline traffic patterns.