Shadowkube: Active Kubernetes Defense

via Behavioral Monitoring and Honeypots

Presented by[Your Name Here]
Reg. No[Your Roll Number Here]
Date[Insert Presentation Date]
AuthorsQingwang Chen, Yuling Liu, et al.
Overview

Presentation Content

01 Abstract & Exec Summary
02 Intro & Security Limitations
03 Research Objectives
04 Literature Review
05 Methodology I: Architecture
06 Methodology II: Baselines
07 Methodology III: Detection
08 Methodology IV: Migration
09 Experimental Setup
10 Results & Conclusion
Section 01

Abstract & Exec Summary

Background

Cloud-native environments rely heavily on Kubernetes. Misconfigurations & vulnerabilities frequently expose clusters to severe attacks (privilege escalation, container escapes).

The Problem

Existing defenses use easily bypassed static rules or high-overhead machine learning (false-positives during traffic bursts) and lack automated mitigation.

Proposed Solution

ShadowKube: Achieves 97.7% TPR with 0% FPR across 43 CVEs, converting compromised nodes into honeypots in seconds.

Future Scope

Integrating LLMs to dynamically handle anomalies and using communication simulation to emulate massive clusters with minimal hardware.

Section 02: Introduction

Cloud-Native Security

  • Orchestration Leader: Kubernetes is the standard for managing container deployments (Docker, Podman) at massive scale.

Architecture Complexity

  • Control Plane: Manages state (kube-apiserver, kube-scheduler, etcd).
  • Data Plane: Hosts workloads (kubelet, pods).
  • Expanded Attack Surface: Minor misconfigurations (over-privileged RBAC, insecure service accounts) allow attacks to rapidly propagate across the entire cluster.
Section 02: Limitations

Current Defensive Limitations

Machine Learning

ML models analyzing syscalls suffer massive false-positives (spiking from 4.9% to 27.1%) during legitimate traffic bursts.

Static Rules

Tools like Falco rely on static file paths. Attackers easily bypass these using symbolic links (e.g., symlinking /secret to /s).

Immediate Termination

Killing a container triggers K8s self-healing. Attackers restart exploits, depleting physical resources in an endless loop.

Section 03

Research Objectives

1. Proactive Defense

Develop a real-time, automated defense system (ShadowKube) that secures clusters without relying on fragile, easily-bypassed static rules.

2. Low-Overhead

Create a lightweight algorithmic approach to model benign behavior and detect anomalies efficiently under strict resource constraints.

3. Active Containment

Achieve transparent in-situ conversion—turning compromised resources into honeypots and migrating attackers silently.

Section 05

Methodology: Architecture

Architecture Overview Baseline Setup Online Detection Threat Migration

Five Core Components

  • Probes: Distributed agents on worker nodes monitoring syscalls.
  • Detector: Evaluates behavior against baselines.
  • Actuator: Formulates and triggers defense strategies.
  • Traffic Proxy: Reroutes malicious external traffic.
  • Shadow Cluster: Isolated decoy to capture attackers.
REAL PROD LIVE CLUSTER 🟢 SHADOW DECOY HONEYPOT TRAP 🔴 SHADOWKUBE GATEWAY USER ATTACK
> [01] USER REQUEST -> ROUTED TO REAL PROD CLUSTER [OK 200] > [02] RCE ATTACK DETECTED -> DIVERTED TO HONEYPOT [TRAPPED]
Section 06

Methodology: Baseline Setup

Architecture Overview Baseline Setup Online Detection Threat Migration
  • Metadata Grouping: Pods grouped by Name, Namespace, Labels, Annotations, and Controlled By.
  • Feature Sequence Extraction: Models benign behavior using Longest Common Subsequence (LCS):
    $$f(e_{ij}, w_t^n) = \max(\{LCS(e_{ij}, \text{seq}) \mid \text{seq} \in w_t^n\})$$
  • Avoiding Fragmented Sequences: Minimum valid length ($ms$) using constant $k$ and coefficient $r$:
    $$ms = \begin{cases} |e_{ij}| \times r, & \text{if } |e_{ij}| \cdot r \ge k \\ k, & \text{otherwise} \end{cases}$$
Section 07

Methodology: Online Detection

Architecture Overview Baseline Setup Online Detection Threat Migration
  • Operation-Specific Quantifiers:
    • File/Command: Minimal Levenshtein Distance between observed and baseline.
    • Network: Add penalty $c$ if destination deviates.
  • Suspicion Score ($d$): Normalized against baseline length $|s|$:
    $$d = \min\left(\left\{ \frac{\text{lev}(e_a^b, s)}{|s|} \ \middle|\ s \in w_a^p, b \in p \right\}\right)$$
  • Sliding Window: Accumulate $D = D + d$ in window $T_i$. Complexity: $\mathcal{O}(n^2)$.
NORM: /usr/bin/python main.py OBSV: /usr/bin/python main.py /bin/sh -c "cat /secret" 0.000 0.714 SCORE (d) BENIGN WORKLOAD d = 0 → NO ANOMALY 🟢 ANOMALY DETECTED D > L → THREAT FLAG 🔴
> [01] SCAN: /usr/bin/python -> DISTANCE: 0.0 -> BENIGN 🟢 > [02] SCAN: /bin/sh -c cat -> DISTANCE: 5.0 -> ANOMALY 🔴
Section 08

Methodology: Threat Migration

Architecture Overview Baseline Setup Online Detection Threat Migration

Prioritizes converting the hijacked node in-place, preserving attacker connections silently.

Production Node Pod 1 HACKED Pod 2 Pod 3 EVACUATION BRIDGE → HEALTHY BACKUP NODE
> [01] HEALTHY: 3 WORKLOAD PODS RUNNING ON PRODUCTION NODE > [02] ALERT: POD 1 INFECTED BY CONTAINER ESCAPE! > [03] RESCUE: EVACUATING POD 2 & POD 3 TO BACKUP NODE > [04] TRAP: PRODUCTION NODE ISOLATED AS HONEYPOT
PHASE 01

Network Reconfig

Dynamically rewrites iptables rules. Silent-routes attacker traffic to Shadow Cluster.

PHASE 02

Pod Sanitation

Terminates benign workloads on target node. Master recreates them on healthy nodes instantly.

PHASE 03

Token Alteration

Swaps production credentials with decoy shadow cluster credentials. Integrates active logging.

Section 09

Experimental Setup

Infrastructure & Stack

  • 6 nodes total (2-core CPU, 4 GB RAM)
  • 4 Production Nodes + 2 Shadow Nodes
  • Kubernetes v1.19.16, Docker v24.0.5
  • Debian OS environment

Vulnerability Testbed

  • 43 severe CVEs across 25 programs (Log4j, Redis, Spring Cloud)
  • Exposed Ports: API Server (8080/6443), Kubelet (10250), Docker (2375)
  • Simulated by 30-member expert Red Team
Section 10

Key Results & Performance

97.7%

True Positive Rate

With 0% False Positives (vs Falco's 11.6% TPR)

5.39s

Honeypot Transition

Full silent conversion via async optimization.

Real-World Deployment (1-Month Public Net)

  • 635 verified attack attempts from 580 IPs.
  • Triggered 23 honeypot conversions automatically.
  • Negligible Overhead: +3.7% CPU during detection, +7.4% CPU during migration.
Conclusion

Summary & Future Directions

Key Takeaways

  • ShadowKube successfully merges behavioral baseline analysis (LCS) with shadow honeypots.
  • Real-time in-situ conversion provides transparent, zero-interruption threat isolation.
  • Maintains production availability with negligible computational overhead.

Future Work

  • LLM Integration: Harnessing large language models to analyze complex logs and dynamically adjust threshold policies.
  • Communication Simulation: Developing fake internal communications to mimic massive clusters using minimal hardware.
References

Literature

  • Chen Q., Liu Y., Tan R., Jin Z., Xiao J., Wang X., Zhang F., Liu Q. (2025). "Shadowkube: enhancing Kubernetes security with behavioral monitoring and honeypot integration." Cybersecurity.
  • Anagnostakis K. G., Sidiroglou S., Akritidis P., Xinidis K., Markatos E., Keromytis A. D. (2005). "Detecting targeted attacks using shadow honeypots." USENIX Security Symposium.
  • Lin Y., Tunde-Onadele O., Gu X. (2020). "CDL: classified distributed learning for detecting security attacks in containerized applications." ACSAC.
  • Schulz K.U., Mihov S. (2002). "Fast string correction with Levenshtein automata." Int'l Journal of Document Analysis and Recognition.
  • Falco (2024). Cloud-native runtime security tool.

Thank You

Questions & Discussion