Kumo: A Security-Focused Serverless Cloud Simulator

1. Problem Statement

Serverless computing abstracts infrastructure management, offering elasticity and cost efficiency, but it obscures critical system-level behaviors such as scheduling, resource sharing, and container reuse. These opaque mechanisms introduce significant security risks that are difficult to analyze on production platforms due to:

• Limited Observability: Tenants cannot see placement decisions or resource contention details.
• High Cost & Lack of Control: Experimenting with attacks on live clouds is expensive and lacks experimental control.
• Tooling Gaps: Existing simulators focus on performance and cost optimization, lacking explicit models for attackers, victims, and security-specific metrics (e.g., co-location probability).

Consequently, there is no principled way to study how serverless design choices (specifically schedulers) influence security outcomes like Co-location Attacks (side-channel risks) and Availability Attacks (Denial-of-Service via resource contention).

2. Methodology: The Kumo Simulator

The authors present Kumo, a discrete-event, security-focused simulator designed to enable controlled, reproducible analysis of serverless security risks.

Core Architecture

• Event-Driven Engine: Simulates invocation arrivals, scheduling decisions, execution, and resource reclamation using a priority queue of events.
• Explicit Modeling: Unlike performance simulators, Kumo treats Attackers and Victims as first-class entities. It tracks their specific interactions with shared resources.
• Modular Design:
  • Workload Generators: Supports Uniform, Poisson, and Bursty arrival patterns.
  • Pluggable Schedulers: Decouples scheduling logic from the execution engine, allowing researchers to swap policies (e.g., Random, DoubleDip, Helper, OpenWhisk) without modifying the core.
  • State Management: Explicitly models workers, containers (warm/cold starts), resource usage (CPU/Memory), and per-worker queuing.
• Metrics Collection: A centralized module tracks security-relevant metrics including:
  • Co-location probability and time to first co-location.
  • Invocation drop rates and tail latency (p95).
  • Cold/warm start rates.

Threat Models

Kumo focuses on two primary attack vectors:

1. Co-location Attacks: An attacker repeatedly invokes functions to increase the probability of sharing a worker with a victim, enabling side-channel attacks.
2. Availability (DoS) Attacks: An attacker injects high-volume legitimate traffic to induce resource contention, causing queuing delays, invocation drops, or increased tail latency for victims.

3. Key Contributions

1. Design and Implementation of Kumo: A configurable, event-driven simulator that explicitly models scheduling, container reuse, resource contention, and queuing with a focus on security.
2. Attacker/Victim Framework: A flexible framework for modeling adversarial workloads interacting with benign tenants, enabling direct measurement of isolation risks and availability degradation.
3. Empirical Case Studies: Two in-depth studies demonstrating how scheduler design and system-level resource management influence distinct classes of security risks.

4. Evaluation and Results

The authors validated Kumo through two complementary case studies.

Case Study A: Attacker–Victim Co-location

• Setup: 512 workers, 200 tenants, 4,000 functions. Compared four schedulers: Random, DoubleDip, Helper, and OpenWhisk.
• Findings:
  • Scheduler Choice is Critical: The choice of scheduler is a "first-order factor" for co-location.
    • DoubleDip: Achieved zero co-location probability by spreading invocations to avoid recent tenant reuse.
    • Random: Exhibited high co-location probability.
    • Helper/OpenWhisk: Fell in between, prioritizing container reuse (warm starts) which inadvertently increased co-location risk.
  • Trade-offs: DoubleDip achieved high isolation without incurring significant cold-start overhead, disproving the notion that isolation requires performance penalties.
  • Time to Co-location: Attackers could achieve co-location orders of magnitude faster on Random and Helper schedulers compared to DoubleDip.

Case Study B: Denial-of-Service (DoS) and Availability

• Setup: Analyzed the impact of attacker intensity, queue length, and cluster scale on victim drop rates and tail latency.
• Findings:
  • Scheduler Impact Diminishes under Saturation: Once resource contention dominates, the specific scheduler policy matters less than system-level factors.
  • Key Drivers of DoS: Availability degradation is primarily governed by service time, queuing policy, and cluster capacity.
  • Queue Length Trade-off: Increasing queue length reduces invocation drops but significantly increases tail latency (converting drops into long delays).
  • Scalability: Increasing cluster size improves availability but exhibits diminishing returns due to stochastic bursts and queuing effects.

5. Significance and Implications

• Distinction of Risk Types: The paper establishes a crucial distinction between scheduler-driven isolation risks (co-location) and system-level resource exhaustion vulnerabilities (DoS).
  • Mitigation for Co-location: Requires intelligent scheduler design (e.g., placement diversity).
  • Mitigation for DoS: Requires system-level defenses (admission control, queue management, capacity scaling) rather than just scheduler tweaks.
• Scheduler as a Security Mechanism: Schedulers should be viewed not just as performance optimizers but as configurable security controls.
• Research Foundation: Kumo provides a reproducible, open-source foundation for exploring security-performance tradeoffs without the cost and opacity of production cloud experiments.
• Reproducibility: The artifact has been awarded the "Results Reproduced" badge by the CCGRID Artifact Evaluation Committee.

In conclusion, Kumo bridges the gap between performance-oriented simulation and empirical security studies, offering a systematic approach to understanding and mitigating security risks in multi-tenant serverless environments.