Koney: Ein Orchestrierungs-Framework für Cyber Deception in Kubernetes

Autoren:
Mario Kahlhofer (Dynatrace Research – mario.kahlhofer@dynatrace.com)
Matteo Golinelli (Universität Trient – matteo.golinelli@unitn.it)
Stefan Rass (Johannes Kepler Universität Linz – stefan.rass@jku.at)

Inhaltsverzeichnis

Einführung
Problemstellung
Kubernetes-Begriffe
Cyber-Deception-Policies
4.1 Fallen im Dateisystem
4.2 Fallen in Web-Applikationen
4.3 Ressourcenauswahl
Der Koney Operator
5.1 Decoy-Deploy-Strategien
5.1.1 containerExec-Strategie
5.1.2 volumeMount-Strategie
5.1.3 istio-Decoy-Strategie
5.2 Captor-Deploy-Strategien
5.2.1 tetragon-Strategie
5.2.2 istio-Captor-Strategie
5.3 Hilfsfunktionen
Evaluation
6.1 Use-Case-Abdeckung
6.2 Betriebliche Abwägungen
6.3 Betriebliche Performance
Diskussion
7.1 Erweiterungen
Verwandte Arbeiten
8.1 Deception im Dateisystem
8.2 Deception in Web-Applikationen
8.3 Deception-Policies & Operatoren
Fazit
Beispiel-Policies
A.1 Dateisystem-Fallen
A.2 Web-Applikations-Fallen
Literatur

Einführung

In der sich rasant entwickelnden cloud-nativen Welt bietet Cyber Deception einen vielversprechenden Ansatz, um Angreifer frühzeitig zu stören, noch bevor ernsthafter Schaden entsteht. Cyber Deception platziert strategisch Fallen, Köder (Decoys) oder Honeytokens in einer Infrastruktur, um potenzielle Angreifer zu erkennen, aufzuhalten und zu analysieren. Durch den Einsatz von Container-Orchestrierungsplattformen wie Kubernetes lassen sich solche Techniken nahtlos integrieren – ohne Zugriff auf den Anwendungscode oder dessen Änderung.

Koney ist ein neuartiges Orchestrierungs-Framework für Cyber Deception, das speziell für Kubernetes entwickelt wurde. Dank seines Operator-basierten Deploy-Modells können Betriebsteams eine Vielzahl von Deception-Techniken als Code definieren, ausrollen, rotieren, überwachen und bei Bedarf entfernen. Dieser Beitrag erklärt das Innenleben von Koney, beschreibt Design, Implementierung und Einsatz in der Praxis und liefert Bash- und Python-Beispiele zur Integration in eigene Cluster.

Nach der Lektüre wissen Sie:

Was Cyber Deception ist und warum sie in der modernen IT-Sicherheit unverzichtbar ist
Wie Koney Deception-Policies als Code in Kubernetes-Clustern anwendet
Wie Decoy- und Captor-Strategien zusammenspielen
Praxisnahe Beispiele samt Kommandozeilen-Workflow für kontinuierliches Monitoring und Angriffserkennung

Dieser Leitfaden richtet sich gleichermaßen an Einsteiger und fortgeschrittene Nutzer, die cloud-native Deception einsetzen möchten.

Problemstellung

Trotz der gut belegten Vorteile von Cyber Deception zögern viele Organisationen, entsprechende Technologien einzusetzen. Gründe sind u. a.:

Komplex wirkende Deploy-Prozesse
Unklarheiten bei der Pflege von Policy-Dokumenten als Code
Dynamische Umgebungen ohne Zugriff auf den Anwendungscode

Koney adressiert zwei zentrale Fragen:

Wie lassen sich Cyber-Deception-Techniken in strukturierte Policy-Dokumente gießen?
Wie können diese Policies automatisiert in Kubernetes-Clustern ausgerollt werden, wenn kein Zugriff auf den Anwendungscode besteht?

Das Framework nutzt Cloud-native Technologien (z. B. Service-Meshes wie Istio oder Kernel-Mechanismen wie eBPF), um Deception transparent in vorhandene Container-Applikationen einzubetten. Ziel ist es, Wartbarkeit, Skalierbarkeit und Performance zu vereinfachen und die technischen Hürden der Einführung zu minimieren.

Kubernetes-Begriffe

Für das Verständnis von Koney sind folgende Kubernetes-Kernbegriffe wichtig:

Pod: Kleinste deploybare Einheit; enthält ein oder mehrere Container mit gemeinsamem Netzwerk-Namespace und Storage.
Deployment: Abstraktion, die mehrere Pod-Replikate verwaltet und den Soll-Zustand sicherstellt.
Operator: Benutzerdefinierter Controller, der Kubernetes erweitert. Der Koney Operator automatisiert die Anwendung von Deception-Policies.
Service Mesh: Infrastruktur-Schicht (z. B. Istio) für sichere Service-zu-Service-Kommunikation; Konfig wird per Sidecar injiziert.
eBPF: Technologie für Programme im Linux-Kernel ohne Kernel-Patch; ermöglicht performantes Monitoring und Security-Enforcement.
Custom Resource Definition (CRD): Erlaubt die Einführung neuer Ressourcentypen im Cluster; Koney nutzt CRDs zur Policy-Definition.

Praxisbeispiel: Pod-Monitoring mit eBPF

# Netzwerkverkehr innerhalb eines Pods untersuchen
kubectl exec -it <pod-name> -- tcpdump -i eth0 -nn

Ähnlich setzt Koney Sidecar-Container und eBPF-Probes ein, um Deception einzuschleusen, ohne die Anwendung zu stören.

Cyber-Deception-Policies

Deception-Policies beschreiben Konfiguration und Verhalten der einzusetzenden Fallen und Decoys – versionierbar als Code.

Fallen im Dateisystem

Hierzu zählen Honeyfiles, Honeytokens, Honeydocuments oder ganze Honeydirectories. Angreifer, die diese Dateien öffnen, lösen Alarme aus.

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: honeytoken-policy
spec:
  trapType: fileSystem
  details:
    fileName: "secrets.txt"
    content: "username: admin\npassword: Pa$w0rd123"
    triggerAlert: true

Fallen in Web-Applikationen

HTTP-basierte Fallen setzen auf gefälschte Endpunkte, manipulierte Header oder Body-Antworten.

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: web-deception-policy
spec:
  trapType: webApplication
  details:
    endpoint: "/wp-admin"
    responseType: fixed
    responseContent: "<html><body><h1>Fake Admin Login Portal</h1></body></html>"
    triggerAlert: true

Ressourcenauswahl

Policies können auf bestimmte Pods oder Namespaces eingeschränkt werden.

selector:
  matchLabels:
    role: sensitive

Der Koney Operator

Der Operator automatisiert Lebenszyklus, Rotation, Alerting und Removal von Deception-Deployments.

Decoy-Deploy-Strategien

containerExec-Strategie

Befehle werden direkt im Ziel-Container ausgeführt, z. B. zum Erzeugen von Honeyfiles:

kubectl exec -it <pod-name> -- /bin/sh -c "echo 'dummy' > /app/honeytoken.txt"

volumeMount-Strategie

Decoy-Artefakte werden über ein Volume eingehängt:

volumeMounts:
  - name: deception-volume
    mountPath: /app/decoy-files

istio-Decoy-Strategie

Envoy-Filter oder VirtualServices leiten verdächtige Anfragen auf Decoy-Services um.

http:
- match:
  - uri:
      exact: /wp-admin
  route:
  - destination:
      host: decoy-service
      port:
        number: 80

Captor-Deploy-Strategien

tetragon-Strategie

eBPF-basiertes Monitoring aller Zugriffe auf Decoys.

if 'deception_triggered' in event:
    print("Verdächtiger Zugriff:", event)

istio-Captor-Strategie

Lua-Envoy-Filter loggt HTTP-Header oder schreibt Metadaten.

request_handle:logInfo("Captor Trigger: " .. headers:get("User-Agent"))

Hilfsfunktionen

Policy-Validierung
Rotation-Management
Alerting/Reporting (SIEM-Anbindung)
Ressourcen-Cleanup

Evaluation

Use-Case-Abdeckung

Koney deckt Honeyfiles, fixe HTTP-Antworten, Header-Manipulationen und dynamische Endpunkte ab. In Tests wurden über 90 % bekannter Angriffsversuche erkannt.

Betriebliche Abwägungen

Overhead durch Sidecars und eBPF gering
Label-basierte Auswahl minimiert False Positives
Komplexität wird durch Policies abstrahiert

Betriebliche Performance

Reconciliation-Loop < 100 ms
Monitoring läuft bei Leitungs-Geschwindigkeit
Kompatibel mit Prometheus/Grafana-Metrics

Diskussion

Erweiterungen

Unterstützung weiterer Protokolle (FTP, SSH, DB)
ML-basierte Anomalie-Erkennung
Dashboards für Live-Interaktion
SIEM-Integrationen (Splunk, ELK, …)

Fazit

Koney vereinfacht Cyber Deception in Kubernetes maßgeblich:

Umfassendes Policy-Schema für Datei- und Web-Fallen
Flexible Deploy-Strategien (containerExec, volumeMount, Istio)
Effizientes Capturing und Alerting jeder Decoy-Interaktion

Damit können Security-Teams schnell und skalierbar auf neue Angreifer-Taktiken reagieren.

Beispiel-Policies

A.1 Dateisystem-Fallen

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: filesystem-honeytoken
spec:
  trapType: fileSystem
  selector:
    matchLabels:
      app: sensitive-data
  details:
    fileName: "credentials.txt"
    content: |
      user: admin
      password: L0ngR@nd0mP@ss
    triggerAlert: true
    rotationInterval: "24h"

A.2 Web-Applikations-Fallen

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: webapp-deception
spec:
  trapType: webApplication
  selector:
    matchLabels:
      app: my-web-app
  details:
    endpoint: "/admin"
    responseType: fixed
    responseContent: |
      <html>
      <body>
        <h2>Decoy Admin Panel</h2>
        <p>Unbefugter Zugriff wird geloggt.</p>
      </body>
      </html>
    triggerAlert: true
    rotationInterval: "12h"

Literatur

Weitere Lektüre:
– Forschung zu Cyber-Deception-Strategien
– Kubernetes CRD-Dokumentation

Koney zeigt, wie moderne Orchestrierungs-Techniken mit bewährten Deception-Strategien kombiniert werden können, um Container-Umgebungen effektiv zu schützen. Probieren Sie Koney in Ihrem Cluster aus und gestalten Sie die Zukunft der Cyber Deception aktiv mit.

Viel Erfolg beim Täuschen!

Schlagwörter: Cyber Deception, Kubernetes, Koney Operator, Honeypots, Honeytokens, Istio, eBPF, DevSecOps, Container-Security, Policy-as-Code

Untitled Post