In Kubernetes: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming in Kubernetes scheitert oft daran, dass Cluster-Sicherheit auf wenige technische Kontrollen reduziert wird: Image-Scanning, Pod Security Standards, vielleicht noch ein Admission Controller. In realen Umgebungen reicht das nicht. Kubernetes ist kein einzelnes Zielsystem, sondern ein Zusammenspiel aus Control Plane, Worker Nodes, API-Zugriffen, Service Accounts, Netzwerkpfaden, Secrets, CI/CD-Prozessen, Registry, Ingress, Observability-Stack und Cloud-Integration. Genau deshalb muss Purple Teaming hier anders gedacht werden als in klassischen Serverlandschaften.

Der operative Kern besteht darin, Angriffswege gegen reale Kubernetes-Artefakte zu simulieren und gleichzeitig zu prüfen, ob Detection, Logging, Response und Härtung tatsächlich greifen. Ein Red-Team-artiger Test ohne Blue-Team-Lerneffekt bleibt Stückwerk. Ein Blue-Team-Workshop ohne realistische Angriffskette bleibt Theorie. Purple Teaming verbindet beides in kurzen, nachvollziehbaren Iterationen. Wer die Grundlagen vertiefen will, findet ergänzende Einordnung unter Purple Teaming, methodische Unterschiede unter Purple Team Vs Red Team Vs Blue Team und praxisnahe Einbettung in Entwicklungsprozesse unter In Devsecops.

In Kubernetes ist die zentrale Frage nicht nur, ob ein Angriff möglich ist, sondern an welcher Stelle der Verteidiger ihn sehen müsste. Ein kompromittierter Pod kann beispielsweise über einen überprivilegierten Service Account an API-Tokens gelangen, über die API neue Pods starten, HostPath-Mounts missbrauchen, Secrets lesen oder sich lateral in andere Namespaces bewegen. Jeder dieser Schritte erzeugt andere Spuren: Container Runtime Events, Kubernetes Audit Logs, API-Server-Aufrufe, Netzwerkflüsse, EDR/XDR-Telemetrie auf dem Node, CloudTrail-ähnliche Events in Managed-Umgebungen und Anomalien in SIEM oder Runtime-Sensoren.

Ein belastbarer Purple-Teaming-Ansatz in Kubernetes betrachtet deshalb immer drei Ebenen gleichzeitig: Angriffspfad, Sichtbarkeit und Gegenmaßnahme. Erst wenn diese drei Ebenen sauber zusammengeführt werden, entsteht ein verwertbares Ergebnis. Ein Beispiel: Das Team simuliert den Missbrauch eines Tokens aus einem Pod-Dateisystem. Danach wird nicht nur dokumentiert, dass der Token lesbar war, sondern auch, ob der API-Aufruf in Audit Logs sichtbar war, ob eine Regel auf ungewöhnliche Token-Nutzung reagiert hat, ob RBAC den Missbrauch begrenzt hat und ob der Incident-Workflow den betroffenen Namespace schnell isolieren konnte.

Der Mehrwert entsteht nicht durch spektakuläre Exploits, sondern durch reproduzierbare Erkenntnisse. In Kubernetes sind viele erfolgreiche Angriffe banal: zu breite RBAC-Rechte, fehlende Network Policies, privilegierte Pods, ungeschützte Metadaten-Endpunkte, schwache Secret-Handhabung, unkontrollierte egress-Verbindungen oder unklare Verantwortlichkeiten zwischen Plattform-, DevOps- und Security-Teams. Purple Teaming deckt diese Lücken nicht nur auf, sondern übersetzt sie in konkrete Detection- und Hardening-Maßnahmen.

Besonders wichtig ist die Abgrenzung zwischen Laborlogik und Produktionsrealität. Ein isolierter Testcluster mit Standard-Logging verhält sich anders als ein produktiver Multi-Tenant-Cluster mit Sidecars, Service Mesh, Admission Policies, GitOps und Cloud-IAM-Verknüpfungen. Deshalb müssen Szenarien immer an die tatsächliche Architektur angepasst werden. In Managed-Umgebungen verschiebt sich der Fokus teilweise von Node-Härtung auf API-Nutzung, IAM-Missbrauch, Workload Identity und Cloud-seitige Telemetrie. Diese Unterschiede werden auch in In Cloud Umgebungen und den Plattformvarianten In Aws sowie In Azure relevant.

Ein gutes Kubernetes-Purple-Teaming startet daher nicht mit Tools, sondern mit einer klaren Frage: Welche realistischen Angriffswege bedrohen die Workloads, und welche Signale müssen entlang dieser Wege sichtbar werden? Erst danach werden Simulation, Detection Engineering, Response und Härtung sinnvoll miteinander verbunden.

Viele Teams konzentrieren sich zu stark auf Container Escape oder spektakuläre Kernel-Exploits. In der Praxis beginnen Kubernetes-Kompromittierungen deutlich häufiger an einfacheren Punkten: unsichere Images, exponierte Anwendungen, schwache Ingress-Konfigurationen, geleakte Tokens, CI/CD-Artefakte, Fehlkonfigurationen in Helm-Charts oder überprivilegierte Deployments. Purple Teaming muss diese realen Eintrittspunkte priorisieren, sonst werden Ressourcen in seltene Spezialfälle investiert, während die alltäglichen Risiken offen bleiben.

Ein typischer Startpunkt ist die Anwendungsebene. Eine RCE in einer Webanwendung innerhalb eines Pods ist oft der erste Schritt. Danach folgt die lokale Enumeration: Welche Umgebungsvariablen sind gesetzt, welche Secrets sind gemountet, welcher Service Account ist aktiv, welche DNS-Namen sind intern erreichbar, welche Tools stehen im Container zur Verfügung, welche Dateisystempfade sind beschreibbar, welche Sidecars laufen mit? Aus Sicht des Purple Teams ist genau diese Phase entscheidend, weil hier sichtbar wird, ob Runtime-Detections auf Shell-Spawns, verdächtige Prozessketten, Netzwerk-Scans oder Token-Zugriffe anschlagen.

Die zweite große Angriffsfläche ist die Kubernetes-API. Wer aus einem kompromittierten Pod einen Token extrahieren kann, versucht fast immer, die API-Rechte dieses Tokens auszunutzen. Das ist kein exotischer Angriffsweg, sondern Standard. Deshalb muss jedes Szenario prüfen, ob Service Accounts minimal berechtigt sind, ob Token-Projektion sauber konfiguriert ist, ob kurzlebige Tokens genutzt werden und ob API-Aufrufe mit ausreichender Granularität protokolliert werden.

• Workload-Einstieg über RCE, Command Injection, SSRF oder unsichere Admin-Endpunkte
• Missbrauch von Service Accounts, Secrets, ConfigMaps und API-Berechtigungen
• Lateral Movement über fehlende Network Policies, interne Services und gemeinsame Namespaces
• Privilegienausweitung durch privilegierte Pods, HostPath-Mounts, CAP_SYS_ADMIN oder unsichere DaemonSets
• Persistenz über neue Deployments, CronJobs, mutierte Images oder manipulierte GitOps-/CI-Prozesse

Eine weitere häufig unterschätzte Fläche ist die Node-Nähe. Nicht jeder Angreifer braucht einen vollständigen Container Escape. Schon der Zugriff auf HostPath-Mounts, Docker- oder Containerd-Sockets, kubelet-nahe Endpunkte oder sensible Host-Verzeichnisse kann reichen, um die Sicherheitsgrenze faktisch zu durchbrechen. Purple Teaming sollte deshalb nicht nur fragen, ob ein Pod privilegiert ist, sondern welche konkreten Fähigkeiten daraus folgen: Kann auf /var/run zugegriffen werden? Ist /proc des Hosts sichtbar? Sind HostNetwork oder HostPID aktiv? Gibt es Debug-Container oder Maintenance-Pods mit Sonderrechten?

Auch Netzwerkpfade sind in Kubernetes oft trügerisch. Teams gehen davon aus, dass Namespaces automatisch isolieren. Das tun sie nicht. Ohne Network Policies ist Ost-West-Kommunikation häufig weit offener als angenommen. Ein kompromittierter Pod kann dann interne Datenbanken, Message Queues, Admin-Interfaces oder Metrics-Endpunkte erreichen. Purple Teaming muss diese Annahmen aktiv testen, statt Architekturdiagrammen zu vertrauen.

Schließlich darf die Lieferkette nicht fehlen. Ein manipuliertes Image, ein kompromittierter Build-Agent oder ein unsicheres Deployment-Template kann denselben Effekt haben wie ein direkter Angriff auf den Cluster. In vielen Umgebungen ist der schnellste Weg zu Cluster-Rechten nicht der Pod selbst, sondern das CI-System, das Deployments ausrollt. Deshalb überschneidet sich Kubernetes-Purple-Teaming fast immer mit Themen aus Threat Modeling, Integration und Und Detection Engineering.

Ein gutes Szenario bildet eine plausible Angriffskette ab, die zur eigenen Umgebung passt. Nicht jedes Unternehmen braucht ein Szenario für Kernel-Exploits, aber fast jedes Unternehmen braucht Szenarien für Token-Missbrauch, Secret-Exfiltration, API-Missbrauch, interne Reconnaissance und Persistenz über Kubernetes-Ressourcen. Purple Teaming in Kubernetes wird dann wertvoll, wenn die Szenarien weder zu harmlos noch unnötig spektakulär sind.

Ein klassisches Szenario beginnt mit einer kompromittierten Anwendung in einem Namespace mit Standard-Service-Account. Das Team prüft, ob der Pod überhaupt einen Token besitzt, ob dieser Token lesbar ist und welche Rechte er hat. Danach folgen API-Abfragen wie das Lesen von Pods, Secrets oder Deployments im Namespace. Wenn das möglich ist, wird getestet, ob neue Pods erzeugt, bestehende Images verändert oder Exec-Zugriffe auf andere Pods durchgeführt werden können. Parallel beobachtet das Blue Team, welche Events sichtbar werden und welche Regeln fehlen.

Ein zweites realistisches Szenario ist Secret-Missbrauch. Viele Anwendungen erhalten Datenbank-Credentials, API-Keys oder Cloud-Zugangsdaten als Umgebungsvariablen oder gemountete Dateien. Ein Angreifer mit RCE liest diese Werte aus und nutzt sie außerhalb des Pods. Purple Teaming muss hier nicht nur die Exfiltration simulieren, sondern auch prüfen, ob Secret-Zugriffe, ungewöhnliche egress-Verbindungen oder nachgelagerte Cloud-Aktionen erkannt werden. Gerade in Managed-Kubernetes-Umgebungen ist die Verbindung zwischen Cluster und Cloud-IAM ein kritischer Punkt.

Ein drittes Szenario ist Lateral Movement über interne Services. Nach der Kompromittierung eines Pods wird das interne Netz kartiert: DNS-Auflösung, Service Discovery, Zugriff auf Metrics-Endpunkte, Admin-UIs, Redis, Elasticsearch, Prometheus, interne APIs oder Datenbanken. Ziel ist nicht blinder Portscan-Lärm, sondern nachvollziehbare Bewegung entlang echter Vertrauensbeziehungen. Solche Übungen lassen sich gut mit Szenarien, Use Cases und Beispiele verbinden.

Ein viertes Szenario betrifft Privilegienausweitung durch Fehlkonfiguration. Ein Pod mit HostPath-Mount auf sensible Verzeichnisse oder mit Zugriff auf den Container Runtime Socket kann genutzt werden, um weitere Container zu starten oder Host-Daten zu lesen. In solchen Fällen muss das Purple Team exakt dokumentieren, welche Konfiguration den Missbrauch ermöglicht hat. Pauschale Aussagen wie „privilegierter Pod ist gefährlich“ reichen nicht. Entscheidend ist, welche konkrete Capability, welcher Mount oder welcher API-Zugriff die Eskalation erlaubt hat.

Ein fünftes Szenario ist Persistenz. In Kubernetes wird Persistenz oft nicht über klassische Malware-Mechanismen erreicht, sondern über legitime Ressourcen: CronJobs, zusätzliche Sidecars, mutierte Deployments, neue Secrets, geänderte Admission-Ausnahmen oder manipulierte GitOps-Quellen. Purple Teaming sollte deshalb testen, ob unautorisierte Änderungen an Workloads, Rollen oder Netzwerkregeln schnell erkannt werden. Wer nur auf Prozess- oder Dateisystemebene detektiert, übersieht oft die eigentliche Persistenz im Cluster-Zustand.

Wichtig ist, dass jedes Szenario mit klaren Abbruchkriterien und Sicherheitsgrenzen durchgeführt wird. In produktionsnahen Clustern dürfen Last, Seiteneffekte und Datenintegrität nicht gefährdet werden. Ein sauberer Ablauf orientiert sich an einer definierten Methodik, einem reproduzierbaren Workflow und einem abgestimmten Playbook. Nur so lassen sich Ergebnisse später vergleichen und Verbesserungen belastbar messen.

Detection in Kubernetes scheitert selten an fehlenden Datenquellen, sondern an fehlender Korrelation. Es gibt Audit Logs, Container Runtime Events, Node-Logs, Netzwerkdaten, Cloud-Logs, Admission-Entscheidungen, Ingress-Logs, Service-Mesh-Telemetrie und Applikationslogs. Trotzdem bleibt ein Angriff oft unsichtbar, weil Signale nicht zusammengeführt oder falsch priorisiert werden. Purple Teaming deckt genau diese Lücke auf.

Die wichtigste Quelle für API-bezogene Angriffe sind Kubernetes Audit Logs. Sie zeigen, wer welche Ressource wann mit welcher Methode angesprochen hat. Ohne sinnvolle Audit-Policy sind diese Logs jedoch entweder zu grob oder so laut, dass niemand sie auswertet. Für Purple Teaming ist deshalb relevant, ob kritische Aktionen wie create, patch, exec, port-forward, secret read, role binding changes oder tokenbezogene Zugriffe sauber erfasst werden. Wenn ein kompromittierter Pod über seinen Token neue Ressourcen anlegt und dieser Vorgang nicht sichtbar ist, liegt kein theoretisches, sondern ein operatives Problem vor.

Auf Runtime-Ebene liefern Sensoren wie eBPF-basierte Werkzeuge, Container Runtime Hooks oder Host-Sensorik wertvolle Hinweise: Shell in einem sonst stateless Web-Container, Start von Netzwerktools, Zugriff auf Service-Account-Dateien, verdächtige Child-Prozesse, Schreibzugriffe auf ungewöhnliche Pfade oder Kontakt zu selten genutzten externen Zielen. Solche Signale sind besonders stark, wenn sie mit Kontext angereichert werden: Namespace, Pod-Name, Image, Deployment, Node, Service Account und Owner-Referenzen.

Netzwerktelemetrie ist in Kubernetes ebenfalls zentral, aber häufig unvollständig. Wer nur North-South-Traffic überwacht, übersieht Ost-West-Bewegungen zwischen Pods und Services. Purple Teaming sollte deshalb prüfen, ob interne Reconnaissance, DNS-Anomalien, Verbindungen zu sensiblen Services oder egress zu unbekannten Zielen sichtbar werden. In Service-Mesh-Umgebungen kann zusätzliche Telemetrie helfen, allerdings nur dann, wenn sie nicht in einem separaten Silo verschwindet.

Ein weiterer blinder Fleck ist die Trennung zwischen Cluster- und Cloud-Sicht. In Managed-Umgebungen kann ein Angriff aus dem Cluster heraus Cloud-Ressourcen missbrauchen, etwa über Workload Identity, IAM-Rollen oder Metadatenzugriffe. Wenn das SOC nur Kubernetes-Logs sieht, aber keine Cloud-Aktivitäten korreliert, bleibt die eigentliche Wirkung des Angriffs verborgen. Genau hier greifen Konzepte aus Und Siem, Und Soc und Und Threat Detection.

• Kubernetes Audit Logs für API-Aufrufe, Rollenänderungen, Secret-Zugriffe und Pod-Manipulationen
• Runtime-Telemetrie für Prozessstarts, Shell-Spawns, Dateizugriffe und verdächtige Syscalls
• Netzwerkdaten für interne Reconnaissance, Lateral Movement und ungewöhnlichen egress
• Cloud-Logs für IAM-Missbrauch, Metadatenzugriffe und nachgelagerte Aktionen außerhalb des Clusters
• CI/CD- und Registry-Logs für manipulierte Images, Deployments und Supply-Chain-Indikatoren

Detection Engineering in Kubernetes braucht außerdem eine saubere Trennung zwischen erwartbarem Admin-Verhalten und verdächtigen Aktionen. Ein kubectl exec durch ein SRE-Team ist nicht automatisch bösartig, aber ein exec aus einem Service-Account-Kontext, der sonst nie interaktiv arbeitet, ist hochrelevant. Purple Teaming hilft, diese Unterschiede anhand echter Betriebsdaten zu modellieren. Dadurch entstehen Regeln, die nicht nur theoretisch korrekt, sondern im Alltag nutzbar sind.

Ein häufiger Fehler ist die Fixierung auf einzelne Tools. Falco, SIEM, EDR, XDR oder Cloud-native Sensoren sind nur Bausteine. Entscheidend ist, ob sie die richtigen Fragen beantworten: Wurde ein Token missbraucht? Wurde ein Pod außerhalb des normalen Deployments erzeugt? Wurde ein Secret gelesen, das der Workload nicht benötigt? Wurde ein privilegierter Container gestartet? Wurde eine Network Policy umgangen oder eine Rolle erweitert? Wer diese Fragen nicht operationalisiert, sammelt Logs ohne Erkenntnisgewinn.

Der häufigste Fehler ist ein zu enger Scope. Es wird ein einzelner Pod getestet, aber nicht die Kette aus Anwendung, Namespace, API, Netzwerk und Cloud-Anbindung. Dadurch entstehen Befunde ohne Kontext. Ein RCE-Befund ist erst dann wirklich relevant, wenn klar ist, ob daraus API-Zugriff, Secret-Diebstahl, laterale Bewegung oder Persistenz folgt. Purple Teaming muss immer den nächsten realistischen Schritt mitdenken.

Ein zweiter Fehler ist die Vermischung von Compliance-Härtung und adversarial Testing. Checklisten wie „kein privileged: true“ oder „readOnlyRootFilesystem gesetzt“ sind sinnvoll, ersetzen aber keine Angriffssimulation. Ein Cluster kann formal gehärtet wirken und trotzdem über schwache RBAC-Rechte oder offene interne Services leicht missbrauchbar sein. Umgekehrt kann ein einzelner Policy-Verstoß wenig kritisch sein, wenn er operativ gut kompensiert wird. Purple Teaming bewertet nicht nur Konfiguration, sondern tatsächliche Ausnutzbarkeit und Sichtbarkeit.

Ein dritter Fehler ist fehlende Reproduzierbarkeit. Teams führen einmalig einen Test durch, dokumentieren grob ein paar Findings und wiederholen das Szenario nie. Damit bleibt unklar, ob spätere Verbesserungen tatsächlich wirken. In Kubernetes ändern sich Images, Deployments, Admission Policies und Cluster-Versionen ständig. Ohne wiederholbare Testschritte verliert jedes Ergebnis schnell an Wert. Deshalb müssen Szenarien versioniert, Voraussetzungen dokumentiert und Erfolgskriterien klar definiert werden.

Ein vierter Fehler ist unzureichende Zusammenarbeit zwischen Plattform-Team, Detection Engineering und Incident Response. Wenn das Plattform-Team nur YAML-Härtung betrachtet, das SOC nur Alerts sieht und niemand die Angriffskette Ende-zu-Ende bewertet, entstehen Lücken an den Übergängen. Purple Teaming lebt von enger Collaboration, klarer Communication und einem abgestimmten Prozess.

Ein fünfter Fehler ist die falsche Tool-Erwartung. Es wird angenommen, dass ein Runtime-Sensor automatisch alle relevanten Kubernetes-Angriffe erkennt. Das ist unrealistisch. Viele kritische Aktionen laufen über legitime API-Aufrufe oder Konfigurationsänderungen, nicht über auffällige Malware-Muster. Wer nur auf Runtime schaut, übersieht API-Missbrauch. Wer nur auf Audit Logs schaut, übersieht Prozess- und Netzwerkverhalten. Erst die Kombination liefert ein belastbares Bild.

Ein sechster Fehler ist die Vernachlässigung von False Positives und Baselines. Kubernetes ist dynamisch. Pods starten und verschwinden, Sidecars erzeugen Rauschen, Operatoren verändern Ressourcen automatisiert. Detection-Regeln, die diesen Kontext nicht kennen, produzieren Alarmmüdigkeit. Purple Teaming muss deshalb nicht nur Angriffe simulieren, sondern auch helfen, normale Betriebsabläufe sauber zu modellieren.

Ein siebter Fehler ist die fehlende Priorisierung nach Angriffsrealität. Wenn ein Team Wochen in seltene Escape-Techniken investiert, aber keine Übung zu Secret-Missbrauch, Token-Diebstahl oder interner Service-Enumeration durchführt, ist der Fokus falsch gesetzt. Genau solche Fehlpriorisierungen werden auch in Fehler und Typische Fehler Beim Purple Teaming immer wieder sichtbar.

Ein sauberer Workflow beginnt mit einer präzisen Zieldefinition. Nicht „Kubernetes testen“, sondern zum Beispiel: Kann ein kompromittierter Web-Pod im Namespace payments Secrets lesen, lateral auf interne Services zugreifen und dabei von Audit- und Runtime-Detections erkannt werden? Solche Ziele sind konkret, messbar und technisch verwertbar. Danach folgt die Scope-Festlegung: betroffene Namespaces, erlaubte Techniken, ausgeschlossene Ressourcen, Lastgrenzen, Datenklassen, Notfallkontakte und Abbruchkriterien.

In der Vorbereitungsphase werden Architektur und Telemetrie gemeinsam gesichtet. Dazu gehören RBAC-Modelle, Service Accounts, Admission Policies, Network Policies, Ingress-Wege, Secret-Management, Logging-Pipelines, Cloud-Identitäten und vorhandene Alerts. Wichtig ist, dass nicht nur Security-Dokumente betrachtet werden, sondern die tatsächliche Laufzeitumgebung. Gerade in Kubernetes weichen deklarierte Soll-Zustände und reale Cluster-Zustände oft voneinander ab.

Die Durchführungsphase sollte in klaren Schritten erfolgen. Zuerst Initial Access oder simulierte Ausgangslage, dann lokale Enumeration, danach API-Missbrauch, Netzwerkbewegung, Privilegienausweitung und Persistenz, soweit im Scope erlaubt. Jeder Schritt wird live mit dem Blue Team gespiegelt: Was wurde gesehen, was nicht, welche Datenquelle war hilfreich, welche Regel war zu breit oder zu eng, welche Gegenmaßnahme hätte den Schritt verhindert? Dieser direkte Austausch ist der operative Kern von Purple Teaming.

Nach jedem Szenario folgt eine technische Nachbereitung. Dabei werden Findings nicht nur als Schwachstellen formuliert, sondern als Kette aus Ursache, Auswirkung, Sichtbarkeit und Abhilfe. Ein gutes Ergebnis lautet nicht „Service Account zu breit“, sondern etwa: „Der Token des Pods X erlaubte list/get auf Secrets im Namespace Y. Der Zugriff war in Audit Logs sichtbar, löste aber keinen Alert aus. Durch Reduktion der RBAC-Rechte, Token-Minimierung und eine Regel auf Secret-Zugriffe außerhalb definierter Controller lässt sich der Pfad schließen.“

Ein praxistauglicher Workflow enthält außerdem eine feste Retest-Logik. Kubernetes ändert sich schnell. Deshalb müssen kritische Szenarien regelmäßig wiederholt werden, idealerweise nach Plattform-Upgrades, Policy-Änderungen, neuen Workload-Klassen oder größeren CI/CD-Anpassungen. Wer Purple Teaming nur als Einzelprojekt versteht, verschenkt den größten Nutzen. Nachhaltig wird es erst über Iteration, einen klaren Ablauf und einen gepflegten Lifecycle.

Die Dokumentation muss so präzise sein, dass ein anderes Team das Szenario reproduzieren kann. Dazu gehören Ausgangsrechte, verwendete Befehle, betroffene Ressourcen, beobachtete Logs, Zeitstempel, Alert-Verhalten, Response-Schritte und empfohlene Änderungen. Nur dann lassen sich Fortschritte später objektiv bewerten.

# Beispiel für eine kontrollierte Prüfung eines Service-Account-Tokens im Pod
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CACERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
APISERVER="https://kubernetes.default.svc"

curl --cacert $CACERT -H "Authorization: Bearer $TOKEN" \
  $APISERVER/api/v1/namespaces/default/pods

# Danach prüfen:
# - Audit-Log-Eintrag vorhanden?
# - Alert auf ungewöhnlichen API-Zugriff vorhanden?
# - War der Token überhaupt notwendig?
# - Sind Rechte auf Namespace oder Ressourcentyp begrenzt?

Solche einfachen Prüfungen sind oft wertvoller als aufwendige Exploit-Ketten, weil sie reale Fehlkonfigurationen direkt sichtbar machen und sich sauber in Betriebsprozesse übersetzen lassen.

Die Qualität eines Purple-Teaming-Projekts zeigt sich nicht an der Zahl der Findings, sondern an der Qualität der abgeleiteten Maßnahmen. In Kubernetes sind Gegenmaßnahmen nur dann wirksam, wenn sie den getesteten Angriffspfad tatsächlich unterbrechen oder sichtbar machen. Allgemeine Härtungsempfehlungen ohne Bezug zum Szenario erzeugen oft Scheinsicherheit.

RBAC ist ein klassisches Beispiel. Die Standardempfehlung lautet „Least Privilege“. Das ist richtig, aber zu ungenau. Nach einem Purple-Team-Szenario muss klar sein, welche Verben auf welche Ressourcen für welchen Service Account unnötig waren. Vielleicht braucht ein Pod get auf ConfigMaps, aber nicht list auf Secrets. Vielleicht darf ein Controller Deployments patchen, aber nicht Pods execen. Solche Unterschiede entscheiden darüber, ob ein kompromittierter Token nur begrenzten Schaden anrichtet oder den Namespace vollständig öffnet.

Admission Policies und Pod Security Controls sind ebenfalls wichtig, aber nur wirksam, wenn sie an reale Missbrauchsmuster angepasst werden. Ein Verbot privilegierter Pods hilft wenig, wenn HostPath-Mounts auf sensible Verzeichnisse weiterhin erlaubt sind. Ein readOnlyRootFilesystem hilft wenig, wenn Secrets als Umgebungsvariablen offenliegen und egress unkontrolliert bleibt. Purple Teaming zeigt, welche Policy-Lücken praktisch ausnutzbar sind und welche nur theoretisch unsauber wirken.

Network Policies werden oft eingeführt, aber nicht validiert. In vielen Clustern existieren Policies nur für einzelne Namespaces oder nur für Ingress, während egress offen bleibt. Ein Purple-Team-Test sollte deshalb immer prüfen, ob ein kompromittierter Pod tatsächlich nur die vorgesehenen Ziele erreichen kann. Wenn DNS, Datenbanken, interne APIs oder Cloud-Endpunkte trotz Policy erreichbar sind, ist die Segmentierung unzureichend.

Runtime-Schutz muss auf konkrete Verhaltensmuster reagieren. Ein Web-Container, der plötzlich /bin/sh startet, Netzwerktools ausführt oder auf Service-Account-Dateien zugreift, ist ein starkes Signal. Aber auch hier gilt: Regeln müssen kontextsensitiv sein. Ein Maintenance-Job darf andere Muster zeigen als ein stateless Frontend. Gute Gegenmaßnahmen kombinieren Prävention und Detection, statt sich auf eine Schicht zu verlassen.

• RBAC auf konkrete Ressourcentypen, Verben und Namespaces reduzieren
• Automount von Service-Account-Tokens deaktivieren, wo kein API-Zugriff nötig ist
• Admission Policies für privilegierte Felder, HostPath, HostNetwork, Capabilities und Images erzwingen
• Network Policies für Ingress und egress mit echten Kommunikationspfaden testen
• Runtime-Detections auf Shell, Token-Zugriff, verdächtige Prozesse und ungewöhnliche Netzwerkziele abstimmen

Ein weiterer zentraler Punkt ist Secret-Management. Secrets sollten nicht nur verschlüsselt gespeichert, sondern auch minimal verteilt werden. Purple Teaming zeigt oft, dass Anwendungen deutlich mehr Zugangsdaten erhalten als nötig. Wenn ein kompromittierter Pod mehrere externe Systeme ansprechen kann, ist das kein reines Secret-Problem, sondern ein Architekturproblem. Hier müssen Plattform- und Anwendungsteams gemeinsam nachschärfen.

Schließlich darf Incident Response nicht fehlen. Eine Gegenmaßnahme ist erst vollständig, wenn klar ist, wie ein kompromittierter Namespace isoliert, ein Token rotiert, ein Deployment zurückgesetzt und ein verdächtiger Pod forensisch gesichert wird. Purple Teaming ohne Response-Verbesserung bleibt unvollständig.

Ein realistisches Beispiel aus einer typischen Unternehmensumgebung: Eine interne Webanwendung läuft in einem Namespace mit mehreren Microservices. Durch eine Command-Injection in einem Diagnose-Endpunkt erhält das Purple Team Befehlsausführung im Container. Der Container ist nicht privilegiert, was zunächst beruhigend wirkt. Bei genauerer Prüfung zeigt sich jedoch, dass ein Service-Account-Token gemountet ist und der Pod egress ins Cluster-Netz hat.

Im ersten Schritt wird lokal enumeriert. Das Team prüft Umgebungsvariablen, gemountete Volumes, DNS-Auflösung und verfügbare Tools. Danach wird der Token verwendet, um die Kubernetes-API abzufragen. Ergebnis: Der Service Account darf Pods im Namespace listen und Secrets lesen. Das ist bereits kritisch, weil mehrere Datenbank-Zugangsdaten und ein API-Key für einen internen Zahlungsdienst als Secrets vorliegen.

Im zweiten Schritt wird geprüft, ob diese Aktionen sichtbar sind. Die Audit Logs enthalten den Secret-Read, aber im SIEM existiert keine Regel dafür, weil Secret-Zugriffe im Namespace als „zu häufig“ eingestuft wurden. Tatsächlich lesen die regulären Anwendungen ihre Secrets aber nur beim Start, nicht interaktiv zur Laufzeit. Genau diese Differenz wurde nie modelliert. Das Purple Team kann also einen hochkritischen Zugriff durchführen, ohne Alarm auszulösen.

Im dritten Schritt wird mit den ausgelesenen Zugangsdaten eine Verbindung zu einem internen Backend aufgebaut. Die Network Policies erlauben egress pauschal innerhalb des Clusters. Dadurch ist laterale Bewegung möglich, obwohl die Anwendung fachlich nie mit diesem Backend sprechen sollte. Auch hier zeigt sich eine typische Lücke: Segmentierung wurde auf Namespace-Ebene angenommen, aber technisch nie erzwungen.

Im vierten Schritt wird Persistenz getestet. Der Service Account darf keine Deployments ändern, aber ConfigMaps patchen. Eine der Anwendungen lädt Konfiguration dynamisch nach. Durch Manipulation einer ConfigMap kann das Verhalten der Anwendung verändert werden, ohne dass ein klassischer Malware-Indikator entsteht. Die Änderung ist im Audit Log sichtbar, aber nicht als sicherheitsrelevant markiert. Das ist eine subtile, aber realistische Form von Persistenz.

Die eigentliche Erkenntnis liegt nicht in der einzelnen Schwachstelle, sondern in der Kette: RCE in App, Token-Missbrauch, Secret-Read, laterale Verbindung, Konfigurationsmanipulation. Jeder Schritt für sich war bekannt oder theoretisch denkbar. Erst die Übung zeigt, dass die Kombination operativ funktioniert und an mehreren Stellen unentdeckt bleibt. Solche Ketten lassen sich gut mit Real World Beispiele, Und Log Analyse und Und Alerting weiter vertiefen.

Die Abhilfen sind entsprechend konkret: Automount des Tokens deaktivieren, wo nicht nötig; RBAC des Service Accounts auf das Minimum reduzieren; Secret-Zugriffe zur Laufzeit detektieren; egress per Network Policy einschränken; ConfigMap-Änderungen an kritischen Anwendungen überwachen; Incident-Playbook für kompromittierte Namespaces definieren. Genau so entsteht aus einem Angriffsszenario ein belastbarer Verbesserungsplan.

Fortschritt in Kubernetes-Sicherheit lässt sich nicht sinnvoll über die Anzahl geschlossener Tickets messen. Purple Teaming braucht Metriken, die technische Wirksamkeit abbilden. Die wichtigste Frage lautet: Wurde ein realistischer Angriffspfad verhindert, erkannt oder zumindest schneller eingegrenzt als zuvor? Alles andere ist Beiwerk.

Sinnvolle Metriken orientieren sich an der Angriffskette. Wie viele der geplanten Schritte waren möglich? Welche davon wurden erkannt? Wie lange dauerte es bis zum ersten Signal? Wie präzise war der Alert? Konnte das Team den betroffenen Pod, Namespace oder Service Account schnell identifizieren? Wurden Response-Maßnahmen korrekt ausgelöst? Solche Kennzahlen sind deutlich wertvoller als allgemeine Aussagen über „verbesserte Sicherheit“.

Reporting muss in Kubernetes zwei Ebenen trennen: technische Detailtiefe für Plattform- und Security-Teams sowie verdichtete Risikobewertung für Verantwortliche. Die technische Ebene dokumentiert exakte API-Aufrufe, YAML-Felder, Rollen, Netzwerkpfade, Logquellen und Reproduktionsschritte. Die Management-Ebene beschreibt, welche geschäftsrelevanten Auswirkungen möglich waren: Zugriff auf Produktionsdaten, Manipulation von Workloads, Ausfallrisiko, Missbrauch von Cloud-Ressourcen oder Umgehung von Segmentierung.

Retests sind unverzichtbar. Ein einmal geschlossener Befund kann durch ein neues Helm-Template, ein Plattform-Upgrade oder ein geändertes Deployment schnell wieder auftauchen. Deshalb sollten kritische Szenarien als wiederkehrende Übungen etabliert werden. Besonders geeignet sind Pfade, die in der Vergangenheit funktioniert haben: Token-Missbrauch, Secret-Read, unautorisierte Pod-Erstellung, egress zu sensiblen Zielen, ConfigMap- oder RoleBinding-Manipulation.

Auch die Qualität der Detection muss separat gemessen werden. Ein Alert, der zehn Minuten zu spät kommt oder ohne Kontext im SIEM landet, ist operativ nur begrenzt nützlich. Purple Teaming sollte deshalb immer prüfen, ob Alerts die nötigen Felder enthalten: Namespace, Pod, Node, Image, Service Account, betroffene Ressource, API-Verb, Zieladresse und empfohlene Erstmaßnahme. Ohne diesen Kontext verliert das SOC wertvolle Zeit.

Langfristig entsteht Reife durch wiederholbare Messung. Dazu gehören definierte Baselines, feste Szenario-Kataloge, priorisierte Angriffspfade und nachvollziehbare Verbesserungszyklen. Wer diese Disziplin aufbaut, kann Purple Teaming in Kubernetes von einer punktuellen Übung zu einem belastbaren Sicherheitsmechanismus entwickeln. Ergänzend helfen strukturierte Ansätze aus Reporting, Dokumentation, Metriken und Erfolg Messen.

Werkzeuge sind in Kubernetes-Purple-Teaming wichtig, aber sie ersetzen keine saubere Hypothese. Ein Tool kann API-Aufrufe automatisieren, Runtime-Events sammeln oder Netzwerkpfade visualisieren. Es beantwortet jedoch nicht automatisch, welche Angriffskette für die eigene Umgebung relevant ist und welche Detection daraus folgen muss. Genau hier scheitern viele Projekte: Es werden Tools eingeführt, bevor klar ist, was gemessen oder getestet werden soll.

Für die Angriffssimulation reichen oft einfache Bordmittel: kubectl, curl, Service-Account-Tokens, Namespaced Test-Workloads und gezielte API-Aufrufe. Für Runtime-Sichtbarkeit kommen Sensoren auf Node- oder eBPF-Basis in Frage. Für Korrelation werden SIEM, Log-Pipelines oder spezialisierte Detection-Plattformen genutzt. In manchen Umgebungen ergänzen EDR/XDR-Agenten auf Worker Nodes die Sicht, in anderen liefern Cloud-native Logs den entscheidenden Kontext.

Wichtig ist die Trennung zwischen Erzeugung, Beobachtung und Auswertung. Ein Tool, das einen Angriff simuliert, sollte nicht gleichzeitig die einzige Quelle für die Bewertung sein. Sonst entsteht ein Zirkelschluss. Besser ist ein Aufbau, bei dem das Purple Team eine Aktion ausführt, während unabhängige Telemetriequellen prüfen, ob diese Aktion sichtbar wurde. So lässt sich objektiv bewerten, welche Kontrollen funktionieren.

Auch Open-Source-Werkzeuge sind in Kubernetes oft völlig ausreichend, wenn sie sauber integriert werden. Entscheidend ist weniger die Lizenzform als die Fähigkeit, Kontext aus dem Cluster zu erfassen und in verwertbare Signale zu übersetzen. Wer sich tiefer mit Werkzeuglandschaften beschäftigen will, findet passende Ergänzungen unter Tools, Tools Liste, Beste Purple Teaming Tools, Open Source Tools und Automation Tools.

Am Ende gilt: Ein einfaches, reproduzierbares Szenario mit klarer Auswertung ist wertvoller als ein komplexes Toolset ohne belastbare Fragestellung. In Kubernetes ist Präzision wichtiger als Show-Effekt. Wer weiß, welche API-Aufrufe, Prozesse, Netzwerkpfade und Konfigurationsänderungen relevant sind, kann mit überschaubaren Mitteln sehr tiefe Erkenntnisse gewinnen.