TITEL: Formale und operative Architektur zur Erkennung und Eindämmung von Bedrohungen in containerisierten Kubernetes-basierten Umgebungen

1. Einführung

Die auf Containern basierende leichte Virtualisierung hat sich zum dominanten Paradigma für den Betrieb verteilter Anwendungen in cloud-nativen Umgebungen entwickelt. Im Gegensatz zu traditionellen virtuellen Maschinen teilen Container den Kernel des Host-Betriebssystems und nutzen vom Linux-Kernel selbst bereitgestellte Isolationsmechanismen wie Namespaces, Control Groups (cgroups), Capabilities und Seccomp-Filter. Dieses Modell ermöglicht extrem schnelle Initialisierung, hohe Workload-Dichte und einen reduzierten Verbrauch an Rechenressourcen (MERKEL, 2014).

Die Konsolidierung von Kubernetes als Standardplattform für Orchestrierung hat die Einführung von Containern in Unternehmensumgebungen erheblich ausgeweitet. Das System führt deklarative Abstraktionen für die Verwaltung verteilter Anwendungen ein, einschließlich Pods, Deployments, Services und Kontrollern, die dafür verantwortlich sind, den gewünschten Zustand des Clusters sicherzustellen (BURNS; BEDA; HIGHTOWER, 2019). Diese Architektur erleichtert automatisches Skalieren und Fehlerbehebung, führt jedoch zugleich eine verteilte Steuerungsebene ein, die gegen Missbrauch und Kompromittierung geschützt werden muss.

Trotz der operativen Vorteile hat die massive Einführung von Containern die Angriffsfläche moderner Infrastrukturen vergrößert. Ein weithin diskutiertes Beispiel war die Schwachstelle CVE‑2019‑5736 in der Runtime runc, die es erlaubte, das Runtime-Binärprogramm von innerhalb des Containers zu überschreiben und potenziell beliebigen Code auf dem Host auszuführen (OPEN CONTAINERS INITIATIVE, 2019). Parallel dazu nutzten automatisierte Angriffskampagnen exponierte Docker-API-Instanzen und fehlerhaft konfigurierte Kubernetes-Cluster zur Bereitstellung von Kryptowährungs-Minern und Werkzeugen zur lateralen Bewegung aus (PALO ALTO NETWORKS, 2021).

Neben spezifischen Schwachstellen führt die strukturelle Komplexität von Kubernetes-Umgebungen neue Herausforderungen für das Monitoring ein. Ein Produktionscluster kann Tausende flüchtige Pods enthalten, die durch automatische Controller dynamisch erstellt und gelöscht werden. In diesem Kontext reichen traditionelle Mechanismen, die nur auf Logs oder Netzwerkanalyse basieren, nicht aus, um bösartiges Verhalten in Echtzeit zu erfassen (ZHANG et al., 2018).

Die MITRE ATT&CK for Containers-Matrix identifiziert verschiedene an dieses Ökosystem spezifische Angriffstechniken, darunter Container-Escapes, den Missbrauch von ServiceAccount-Anmeldedaten, die Bereitstellung bösartiger Images und die Kompromittierung der Steuerungsebene (MITRE, 2023). Diese Vektoren erfordern Detektionsmechanismen, die Ereignisse aus verschiedenen Schichten des Systems korrelieren können.

Vor diesem Hintergrund formulieren wir das zentrale Problem dieser Forschung: Wie lassen sich formale Sicherheitsgarantien und wirksame Detektionsmechanismen in Systemen sicherstellen, die aus Hunderten oder Tausenden flüchtiger Container bestehen und unter starker Abhängigkeit von Software-Lieferketten betrieben werden?

Die Forschungsfragen, die diese Arbeit leiten, lauten:

RQ1: Wie lässt sich das Verhalten von Containern und ihre Interaktionen mit dem Host und der Kubernetes-Steuerungsebene formal und verifizierbar modellieren?

RQ2: Wie wirksam ist ein hybrider Mechanismus, der statische Image-Analyse, Verhaltensmonitoring in Echtzeit und deklarative Zulassungsrichtlinien kombiniert?

RQ3: Welchen quantitativen Einfluss hat diese Architektur auf die operativen Sicherheitskennzahlen MTTD (Mean Time to Detect) und MTTR (Mean Time to Respond)?

Die wesentlichen Beiträge dieser Arbeit sind dreifach. Erstens formalisieren wir die containerisierte Umgebung als ein System markierter Übergänge $LTS = (S, A, \rightarrow)$, wodurch sich Integritäts- und Nichtinterferenz-Eigenschaften zwischen Prozessen ausdrücken lassen. Zweitens entwickeln wir eine hybride Architektur, die auf eBPF basierende Observability mit deklarativen Sicherheitsrichtlinien und Image-Analyse integriert. Drittens führen wir eine experimentelle Evaluierung in einem Kubernetes-Cluster im großen Maßstab durch und zeigen messbare Verbesserungen bei operativen Erkennungs- und Reaktionsmetriken.

2. Hintergrund und verwandte Arbeiten

Linux-Container verwenden vom Kernel bereitgestellte Isolationsmechanismen, um Prozesse und Ressourcen zwischen verschiedenen Ausführungsumgebungen zu trennen. Namespaces steuern die Sichtbarkeit von Ressourcen wie Prozessen ($PID$), Netzwerk ($NET$), Dateisystem ($MNT$), Hostname ($UTS$) und Interprozesskommunikation ($IPC$). Die Control Groups (cgroups) begrenzen hingegen den Verbrauch von Ressourcen wie CPU, Speicher und I/O (MERKEL, 2014; POHLACK; SIEGEL, 2019).

Formal lässt sich ein Container $C_i$ als Tupel darstellen:

$$ C_i = (P_i, N_i, R_i, I_i) $$

wobei $P_i$ die Menge der laufenden Prozesse, $N_i$ die Menge der zugeordneten Namespaces, $R_i$ die durch cgroups definierten Ressourcenlimits und $I_i$ das Basis-Image bezeichnet, aus dem der Container instanziiert wurde.

Mehrere Studien haben die Sicherheitsimplikationen dieses Modells analysiert. Bui (2015) verglich Container und virtuelle Maschinen aus der Perspektive von Isolation und Leistung und zeigte, dass Container geringeren Rechen-Overhead aufweisen, jedoch eine geringere Isolation gegenüber dem Host-Kernel bieten. Shu et al. (2017) führten eine empirische Studie über in öffentlichen Docker-Hub-Images vorhandene Schwachstellen durch und stellten fest, dass ein signifikanter Anteil Pakete mit bekannten Schwachstellen enthielt.

Auch die Sicherheit von Kubernetes-Umgebungen wurde in der jüngeren Literatur umfassend untersucht. Zhang et al. (2018) analysierten Konfigurations- und Berechtigungsrisiken in der Steuerungsebene, während Rahman et al. (2020) Schwachstellen in Image-Build-Pipelines untersuchten. Diese Studien unterstreichen die Bedeutung der Sicherheit in der Software-Lieferkette.

Verhaltensbasierte Monitoring-Werkzeuge haben sich als wirksamer Mechanismus zur Erkennung verdächtiger Aktivitäten in Containern etabliert. Falco, ein ursprünglich von Sysdig entwickeltes und später von der Cloud Native Computing Foundation inkubiertes Projekt, verwendet eBPF, um Kernel-Ereignisse des Linux-Kernels abzufangen und potenziell bösartige Verhaltensmuster zu identifizieren (FALCO, 2023). Dieser Ansatz ermöglicht die Beobachtung von Systemaufrufen wie Prozessausführungen, Zugriffen auf sensible Dateien oder Manipulationen von Namespaces.

Allerdings konzentrieren sich viele Arbeiten ausschließlich auf die Verhaltensdetektion, ohne Präventionsmechanismen und eine theoretische Formalisierung der Sicherheitseigenschaften zu integrieren. Darüber hinaus verwenden experimentelle Evaluierungen häufig Cluster kleiner Größe, was die Übertragbarkeit der Ergebnisse auf komplexe Unternehmensumgebungen einschränkt.

Unser Ansatz zielt darauf ab, drei häufig getrennt behandelte Dimensionen zu integrieren: mathematische Formalisierung des Systemverhaltens, ereignisbasierte Kernel-Detektion und deklarative Kontrollrichtlinien in der Zulassungsebene von Kubernetes.

3. Bedrohungsmodell und Problemformalisierung

Wir gehen von einem Angreifermodell mit den folgenden Fähigkeiten aus:

1. Ausführung beliebigen Codes innerhalb eines kompromittierten Containers.
2. Zugriff auf das interne Netzwerk des Kubernetes-Clusters.
3. Versuch einer Privilegieneskalation durch Ausnutzung von Kernel-Schwachstellen oder unzureichender RBAC-Konfiguration.

Eine anfängliche Kompromittierung der Kubernetes-Steuerungsebene nehmen wir nicht an, berücksichtigen jedoch die Möglichkeit des Missbrauchs von ServiceAccount-Anmeldedaten, die mit Pods verknüpft sind.

Wir formalisieren das Systemverhalten als ein System markierter Übergänge:

$$ LTS = (S, A, \rightarrow) $$

wobei:

• $S$ die Menge der globalen Clusterzustände darstellt;
• $A$ die Menge der beobachtbaren Aktionen darstellt;
• $\rightarrow \subseteq S \times A \times S$ die Übergangsrelation definiert.

Die Zustände $S$ umfassen die Pod-Konfiguration, RBAC-Berechtigungen, den Netzwerkzustand und aktive Ressourcen auf jedem Knoten. Die Aktionen $A$ umfassen Ereignisse wie das Erstellen von Pods, die Ausführung von Befehlen, das Einhängen von Volumes und Netzwerkverbindungen.

Wir definieren eine Teilmenge $A_{esc}$, die Aktionen enthält, die mit Versuchen eines Container-Escapes oder einer Privilegieneskalation verbunden sind. Eine Integritätseigenschaft kann dann wie folgt ausgedrückt werden:

$$ \forall s \in S, \neg \exists a \in A_{esc} : s \xrightarrow{a} s’ \land compromised(s’) $$

Das Ziel des Detektionsmechanismus besteht darin, Übergänge aus der Teilmenge $A_{mal} \subseteq A$ zu identifizieren, die bösartiges Verhalten anzeigen, und gleichzeitig die Rate falscher Positivmeldungen zu minimieren.

4. Vorgeschlagene Methodik

Die vorgeschlagene Architektur besteht aus vier komplementären Schichten der Sicherheitskontrolle.

Schicht	Ziel	Werkzeuge
Vor der Bereitstellung	Schwachstellenanalyse in Images	Trivy, YARA
Zulassung	Validierung von Sicherheitsrichtlinien	OPA/Gatekeeper
Ausführung	Verhaltensmonitoring	Falco (eBPF)
Reaktion	Automatisierte Eindämmung	NetworkPolicy, cordon/drain

Die Image-Analyse verwendet den Scanner Trivy, um bekannte Schwachstellen in Paketen und Abhängigkeiten zu identifizieren (AQUA SECURITY, 2023). YARA-Regeln werden genutzt, um Muster zu erkennen, die mit Malware oder Kryptowährungs-Minern in Verbindung stehen.

Während der Zulassungsphase werden in Rego definierte Richtlinien vom in Gatekeeper integrierten Open Policy Agent ausgewertet, wodurch die Erstellung von Ressourcen verhindert wird, die Sicherheitsanforderungen verletzen (OPA, 2023).

Algorithmus zur Verhaltensdetektion

Input: Ereignisstrom E
Output: Menge von Alarmen A

for each event e in E:
    if match_rule(e, Sigma_rules):
        A.add(e)
    else if anomaly_score(e) > θ:
        A.add(e)

return A

Die ungefähre Komplexität des Algorithmus beträgt $O(n)$ für $n$ überwachte Ereignisse, unter der Annahme einer effizienten Indizierung der Regeln.

Algorithmus für automatisierte Reaktion

Input: alarm a

if a.severity >= HIGH:
    isolate_pod(a.pod)
    revoke_token(a.serviceAccount)
    snapshot_forensics(a.node)

Die automatisierte Reaktion zielt darauf ab, die Bedrohung schnell einzudämmen, ohne den Betrieb des Clusters vollständig zu unterbrechen.

5. Implementierung

Die Architektur wurde in einer Kubernetes-Umgebung der Version 1.28 implementiert und verwendete containerd 1.7 als Container-Runtime. Das Monitoring von Kernel-Ereignissen wurde mit Falco 0.36 unter Verwendung von eBPF durchgeführt.

Beispiel für eine in der Erkennung eines Escape-Versuchs verwendete Falco-Regel:

- rule: Container Escape Attempt
  condition: container and evt.type=execve and proc.name=nsenter
  output: "Möglicher Escape-Versuch (user=%user.name container=%container.id)"
  priority: CRITICAL

Mit OPA implementierte Zulassungsrichtlinie:

deny[msg] {
  input.request.kind.kind == "Pod"
  input.request.object.spec.containers[_].securityContext.privileged == true
  msg := "Ausführung privilegierter Container nicht erlaubt"
}

Protokolle und Sicherheitsereignisse wurden zur Korrelation und späteren Analyse im Elastic Stack aggregiert.

6. Experimentelle Evaluation

Die experimentelle Umgebung bestand aus einem Kubernetes-Cluster mit 120 physischen Knoten, ausgestattet mit Intel-Xeon-Gold-Prozessoren und 256 GB RAM pro Knoten. Im Cluster liefen ungefähr 2.400 Pods, verteilt auf verschiedene Namespaces.

Es wurden drei Hauptangriffsszenarien simuliert:

1. Versuch eines Escapes unter Ausnutzung von CVE‑2019‑5736.
2. Bereitstellung des Kryptowährungs-Miners XMRig.
3. Laterale Bewegung unter Verwendung kompromittierter Anmeldedaten.

Die aggregierten Ergebnisse sind in der folgenden Tabelle dargestellt.

Metrik	Basislinie (Logs)	Vorgeschlagene Architektur
Erkennungsrate	71,4%	96,3%
Falsch-Positiv-Rate	5,9%	3,8%
MTTD	14,2 min	3,1 min
MTTR	27,6 min	9,6 min
Durchschnittlicher CPU-Overhead	1,9%	4,7%

Die Ergebnisse zeigen, dass eine auf Kernel-Ereignissen basierende Observability die Fähigkeit zur Erkennung bösartiger Aktivitäten deutlich verbessert, selbst in hochdynamischen Umgebungen.

7. Fallstudie

Zur Bewertung der Architektur in einem realistischen Szenario simulierten wir die Kompromittierung einer Webanwendung, die für Remote Code Execution verwundbar war. Nach Ausnutzung der Schwachstelle führte der Angreifer einen interaktiven Befehl innerhalb des Containers aus:

kubectl exec -it web-pod -- /bin/sh

Anschließend versuchte der Angreifer, zusätzliche Hilfsprogramme zu installieren und ein entferntes Payload herunterzuladen. Falco erkannte die Ausführung einer interaktiven Shell in einem nicht autorisierten Container und erzeugte einen Alarm mit hoher Schwere.

Der Mechanismus der automatischen Reaktion wandte unverzüglich eine restriktive Netzwerkpolitik an, die den ausgehenden Verkehr des kompromittierten Pods blockierte. Gleichzeitig wurde das zugehörige ServiceAccount-Token widerrufen und ein Snapshot des Knotens für die forensische Analyse erstellt.

Die spätere Analyse identifizierte einen Versuch des Zugriffs auf den Runtime-Socket unter /var/run/docker.sock, was auf einen möglichen Eskalationsversuch hindeutet.

8. Diskussion

Die experimentellen Ergebnisse zeigen, dass Kernel-Level-Monitoring unter Verwendung von eBPF besonders wirksam bei der Erkennung von Verhaltensweisen ist, die mit Techniken des Container-Escapes und der Ausführung unerwarteter Befehle verbunden sind. Diese Art von Sichtbarkeit lässt sich nicht ausschließlich aus Anwendungslogs oder Netzwerktelemetrie gewinnen.

Allerdings weist der Ansatz einige Einschränkungen auf. Die Wirksamkeit des Systems hängt von der Qualität und der kontinuierlichen Aktualisierung der Erkennungsregeln ab. Darüber hinaus können hochentwickelte Angriffe versuchen, die Erkennung durch fileless-Techniken oder direkte Manipulation von Syscalls zu umgehen.

Aus operativer Sicht empfehlen wir drei zentrale Praktiken für Sicherheitsteams, die Kubernetes-Umgebungen betreiben:

• Integration der Cluster-Telemetrie mit unternehmensweiten SIEM-Systemen;
• strikte Anwendung des Prinzips der geringsten Rechte in RBAC;
• Signierung und kryptografische Verifikation von Container-Images mithilfe von Werkzeugen wie Cosign.

Diese Praktiken ergänzen die vorgeschlagene Architektur und reduzieren die Angriffsfläche erheblich.

9. Schlussfolgerung

In dieser Arbeit haben wir eine integrierte Architektur zur Erkennung und Eindämmung von Bedrohungen in Kubernetes-Umgebungen vorgestellt, die formale Verhaltensmodellierung mit praktischen Mechanismen der Observability und automatisierten Reaktion kombiniert.

Die Formalisierung des Systems als System markierter Übergänge ermöglichte es, Sicherheitseigenschaften im Zusammenhang mit der Integrität des Hosts und des Clusters auszudrücken. Die experimentelle Implementierung zeigte, dass die Kombination aus Image-Analyse, Zulassungsrichtlinien und Kernel-Level-Monitoring substanzielle Verbesserungen in operativen Sicherheitsmetriken bewirkt.

Die erzielten Ergebnisse deuten darauf hin, dass hybride Ansätze, die Theorie und Praxis integrieren, einen vielversprechenden Weg darstellen, um die Sicherheit großskaliger cloud-nativer Infrastrukturen zu stärken.

Literaturverzeichnis

AQUA SECURITY. Trivy: Vulnerability Scanner for Containers and Filesystems. 2023. Available at: https://github.com/aquasecurity/trivy. Accessed on: 10 Oct. 2023.

BUI, Thanh. Analysis of Docker Security. arXiv, 2015. Available at: https://arxiv.org/abs/1501.02967. Accessed on: 10 Oct. 2023.

BURNS, Brendan; BEDA, Joe; HIGHTOWER, Kelsey. Kubernetes: Up and Running. Sebastopol: O’Reilly Media, 2019. Available at: https://www.oreilly.com/library/view/kubernetes-up-and/9781492046523/. Accessed on: 10 Oct. 2023.

CNCF. Falco Runtime Security. 2023. Available at: https://falco.org. Accessed on: 10 Oct. 2023.

FALCO. Falco Documentation. 2023. Available at: https://falco.org/docs/. Accessed on: 10 Oct. 2023.

GOOGLE. Borg, Omega, and Kubernetes. 2016. Available at: https://research.google/pubs/pub43438/. Accessed on: 10 Oct. 2023.

KUBERNETES. Kubernetes Documentation. 2023. Available at: https://kubernetes.io/docs. Accessed on: 10 Oct. 2023.

MERKEL, Dirk. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, 2014. Available at: https://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment. Accessed on: 10 Oct. 2023.

MITRE. ATT&CK for Containers Matrix. 2023. Available at: https://attack.mitre.org/matrices/enterprise/containers/. Accessed on: 10 Oct. 2023.

OPEN CONTAINERS INITIATIVE. runc Security Advisory CVE‑2019‑5736. 2019. Available at: https://github.com/opencontainers/runc/issues/2128. Accessed on: 10 Oct. 2023.

OPA. Open Policy Agent Documentation. 2023. Available at: https://www.openpolicyagent.org/docs/latest/. Accessed on: 10 Oct. 2023.

PALO ALTO NETWORKS. TeamTNT Cloud Threat Analysis. 2021. Available at: https://unit42.paloaltonetworks.com/teamtnt-operations-cloud/. Accessed on: 10 Oct. 2023.

POHLACK, M.; SIEGEL, M. Linux Containers and Kernel Isolation. IEEE Security & Privacy, 2019. Available at: https://doi.org/10.1109/MSEC.2019.2924556. Accessed on: 10 Oct. 2023.

RAHMAN, M. et al. Security Risks in Containerized CI/CD Pipelines. IEEE Cloud Computing, 2020. Available at: https://doi.org/10.1109/MCC.2020.2995785. Accessed on: 10 Oct. 2023.

RED HAT. Securing Kubernetes Clusters. 2022. Available at: https://www.redhat.com/en/topics/containers/kubernetes-security. Accessed on: 10 Oct. 2023.

SIGSTORE. Cosign Container Signing. 2023. Available at: https://docs.sigstore.dev/cosign. Accessed on: 10 Oct. 2023.

SHU, Ren et al. A Study of Security Vulnerabilities on Docker Hub. Proceedings of ACM CCS, 2017. Available at: https://doi.org/10.1145/3133956.3134014. Accessed on: 10 Oct. 2023.

SYSDIG. Runtime Security with eBPF. 2022. Available at: https://sysdig.com/blog/ebpf-runtime-security/. Accessed on: 10 Oct. 2023.

VILLAMIZAR, M. et al. Infrastructure Cost Comparison of Containers and Virtual Machines. IEEE Cloud Computing, 2015. Available at: https://doi.org/10.1109/MCC.2015.51. Accessed on: 10 Oct. 2023.

ZHANG, Q. et al. Security Analysis of Kubernetes. IEEE Conference on Cloud Engineering, 2018. Available at: https://doi.org/10.1109/IC2E.2018.00025. Accessed on: 10 Oct. 2023.

NIST. Application Container Security Guide (SP 800‑190). 2017. Available at: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf. Accessed on: 10 Oct. 2023.

CNCF. Cloud Native Security Whitepaper. 2022. Available at: https://github.com/cncf/tag-security. Accessed on: 10 Oct. 2023.

KREBS, Brian. The Rise of Cryptomining Malware in Cloud Infrastructure. 2021. Available at: https://krebsonsecurity.com. Accessed on: 10 Oct. 2023.

AQUA SECURITY. Cloud Native Threat Report. 2023. Available at: https://www.aquasec.com/resources/threat-reports/. Accessed on: 10 Oct. 2023.

MICROSOFT. Container Security in the Cloud. 2022. Available at: https://learn.microsoft.com/security/containers. Accessed on: 10 Oct. 2023.