Cyberbedrohungen
Bedrohung durch Sidecar Container Injection
Sidecar-Container in Kubernetes (K8s)-Clustern erweitern zwar die Funktionalität, erschweren aber auch die Erkennung von Kompromittierung. Wir zeigen, wie Angreifer die Sidecar-Injection-Technik nutzen können und wie der Schutz dagegen aussieht.
Save to Folio
Kubernetes (K8s) ist eine Open Source-Plattform für die Container-Orchestrierung, die die Bereitstellung, Skalierung und den Betrieb von Anwendungscontainern automatisieren soll. Container sind leichtgewichtige, eigenständige, ausführbare Softwarepakete, die alles enthalten, was zur Ausführung einer Software benötigt wird, einschließlich Code, Laufzeit, Systemtools, Bibliotheken und Einstellungen. Container sind voneinander und vom Hostsystem isoliert. Theoretisch sollte nur ein Prozess pro Container laufen. Nur die Hauptanwendung sollte innerhalb eines Containers ausgeführt werden. Es kann jedoch vorkommen, dass andere Prozesse, z. B. für die Protokollierung und Überwachung, ausgeführt werden müssen. Anstatt beide Prozesse im selben Container laufen zu lassen, wird dann ein weiterer Container bereitgestellt.
Sidecar-Container in der Orchestrierung
In Kubernetes und der Container-Orchestrierung bezieht sich ein „Sidecar“ auf ein Design, bei dem ein zusätzlicher Container neben dem Hauptanwendungscontainer im selben Pod läuft, um dessen Funktionalität zu erweitern oder zu verbessern. Der Sidecar und der Hauptcontainer teilen sich denselben Lebenszyklus und dasselbe lokale Netzwerk.
Sidecar-Container sind praktisch für die Modularisierung von Merkmalen und Funktionen, die nicht direkt mit der Hauptanwendungslogik zusammenhängen, aber dennoch ihre Bedeutung für einen effizienten Betrieb haben. Die Aufteilung dieser Aufgaben in verschiedene Container hilft, das Prinzip der alleinigen Verantwortung zu verwirklichen, und macht das System besser verwaltbar.
Es gibt einige Möglichkeiten, Sidecar-Container rechtmäßig zu Protokollierungszwecken zu verwenden, z. B:
- leitet die Anwendungs-Logs an seine Standardausgabe weiter (Bild 1).
- betreibt einen Logging Agent, um Protokolle vom Anwendungscontainer abzurufen (Bild 2).
Man kann also sagen, ein Sidecar-Container ermöglicht:
- einen zusätzlichen Container in demselben Pod zu betreiben,
- Daten aus einer externen Quelle in einen lokalen Speicher zu übertragen, auf den der Hauptcontainer zugreift und
- einen gemeinsamen Lebenszyklus, gemeinsame Ressourcen und eine gemeinsamen Netzwerkumgebung zu erhalten.
Vor- und Nachteile von Sidecar Containern
Dies sind die wichtigsten Vorteile der Verwendung von Sidecar Containern:
- Isolierung. Die Kernanwendung arbeitet autonom in einem Container, während der Sidecar zusätzliche Prozesse und Dienstprogramme verwaltet. Er verbirgt den Code der Hauptanwendung vor externen Diensten, die mit ihr interagieren, und hilft, Probleme zu isolieren.
- Schnelles Deployment. Die Bereitstellung eines Sidecar Containers ist unkompliziert und oft einfacher als die Einbindung zusätzlicher Funktionen direkt in den primären Anwendungscontainer.
- Skalierbarkeit. Nach der Einrichtung von Sidecar-Containern lässt sich deren Vorhandensein mühelos erweitern, um mehr Pods unterzubringen. Es bleibt genauso unkompliziert.
Andererseits hat die Verwendung von Sidecar-Containern auch folgende Nachteile:
- Auslastung der Ressourcen. Zusätzliche Container führen zu einer erhöhten Speicher- und CPU-Auslastung. Aus Sicht der Ressourcen ist es oft ressourceneffizienter, alle Prozesse in einem Container zu konsolidieren oder zugehörige Aufgaben auf Knotenebene auszuführen.
- Betriebliche Komplexität. Durch den Einsatz von Sidecars erhöht sich die Anzahl der zu überwachenden Container und die Komplexität ihrer Relationen untereinander. Ein umfassendes Überwachungssystem ist erforderlich, um beispielsweise die genauen Auswirkungen des Ausfalls eines Sidecar Containers auf die Hauptanwendungen zu erkennen.
- Herausforderungen bei der Synchronisierung. Der Abgleich von Aktualisierungen zwischen dem Hauptanwendungscontainer und den unterstützenden Sidecars erfordert zusätzlichen Aufwand. Die Sicherstellung nahtloser Aktualisierungen über alle miteinander verknüpften Komponenten hinweg kann eine Herausforderung sein.
Sidecar Injection
Die Kubernetes-Bedrohungsmatrix bezweckt, ein strukturiertes Verständnis der Taktiken, Techniken und Verfahren (TTPs) zu vermitteln, die potenzielle Angreifer gegen Kubernetes-Setups einsetzen könnten. In Anlehnung an MITRE ATT&CK bietet diese Matrix eine Momentaufnahme möglicher TTPs, die ein Angreifer während seines Angriffs nutzen könnte. Die Bedrohungsmatrix bietet auch spezifische Gegenmaßnahmen, die auf Kubernetes-Systeme und Angriffsmethoden zugeschnitten sind.
Eine dieser Techniken unter den Ausführungstaktiken wird als Sidecar Injection (MS-TA9011) bezeichnet und wird wie folgt beschrieben:
"Ein Kubernetes-Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsamen Speicher- und Netzwerkressourcen … So arbeiten beispielsweise Service-Mesh-Proxys als Sidecars in den Pods der Anwendungen. Angreifer können ihren Code ausführen und ihre Aktivitäten verbergen, indem sie einen Sidecar-Container in einen legitimen Pod einfügen (injizieren), anstatt einen eigenen Pod im Cluster auszuführen." (Microsoft Bedrohungsmatrix für K8s)
Diese Technik steht im Zusammenhang mit der MITRE ATT&CK for Containers-Technik namens Deploy Container (T1610). Die Sidecar Injection-Technik lässt sich auch dann einsetzen, wenn ein Angreifer den aktuell laufenden Sidecar-Container kompromittiert, um dessen Verhalten zu ändern. Dies kann über die API oder das kubectl-Tool erfolgen, um neue Software zu installieren und andere Binärdateien, wie z. B. Kryptowährungs-Miner, auszuführen.
Kurz gesagt, ist die Sidecar-Container-Injektion eine Technik, bei der der Angreifer versucht, unentdeckt zu bleiben, indem er seine Malware in einen Sidecar-Container einschleust oder sogar einen neuen Container bereitstellt, um den Cluster des Opfers zu kompromittieren und gleichzeitig unentdeckt zu bleiben.
Methoden der Sidecar Injection
Es gibt viele Möglichkeiten, wie Angreifer Sidecar Injection ausnutzen können, um Container innerhalb eines Clusters zu kompromittieren:
- Nutzung von kubectl: Wenn der Angreifer in der Lage ist, kubectl in einem der Container zu installieren, könnte er je nach den Berechtigungen dieses einfache Skript ausführen, um einen Kryptominer auf dem letzten Container jedes Pods zu installieren, der mehr als einen Container laufen hat.
- Ohne kubectl: Wenn der Angreifer nicht in der Lage ist, kubectl zu installieren, um die Sidecar Injection durchzuführen, kann er immer noch den API-Server, curl und andere Befehle nutzen, solange er Zugriff auf die erforderlichen Dateien hat. Die wichtigsten Voraussetzungen dafür sind die URL des Kube-API-Servers, das Bearer Token und der Dateipfad des CA-Zertifikats. Weitere technische Details bietet der Originalbeitrag.
Entschärfung der Sidecar Injection
Neben einer geeigneten Laufzeit-Sicherheitslösung zur Überwachung aller Container innerhalb des Clusters gibt es laut der Microsoft Threat Matrix für K8s noch einige weitere Maßnahmen, um die Wahrscheinlichkeit und die Auswirkungen dieser Angriffe in Ihrer Kubernetes-Umgebung zu verringern:
- MS-M9003: Befolgen des Prinzips der geringsten Privilegien - Verhindern, dass unnötige Benutzer und Dienstkonten neue Pods und Controller erstellen.
- MS-M9013: Einschränkung von Containern mit übermäßigen Berechtigungen - Einschränkung von Containern mit zu hohen Berechtigungen im Cluster unter Verwendung eines Admission Controllers.
- MS-M9005.003: In Kubernetes-Cluster bereitgestellte Gate-Images - Beschränkung der Bereitstellung neuer Container aus einer vertrauenswürdigen Lieferkette
Bewährte Praktiken für Sidecar Container
Unternehmen können ihre Kubernetes-Setups gegen diese Bedrohung für Sidecar-Container schützen, indem sie die folgenden Sicherheitsempfehlungen anwenden:
Stellen Sie sicher, dass es einen triftigen Grund für die Trennung der Container gibt.
Die Handhabung von Sidecar-Containern wird kompliziert, wenn es viele Container gibt. Wie jeder Standardcontainer erfordern sie Monitoring, Updates und Ressourcenzuweisung. Werden diese Anforderungen übersehen, kann dies die Effizienz des Clusters gefährden.
Angesichts dieser Komplexität sollten Sidecar-Container nur dann eingebunden werden, wenn sie der Hauptanwendung klare Vorteile bieten. Beispielsweise könnte man die Hauptanwendung um Protokollierungsfunktionen oder ein in einer anderen Programmiersprache entwickeltes Dateisystem erweitern. Eine gute Richtlinie ist, dass Sidecar-Container die Leistung der Anwendung verbessern und nicht behindern sollten.
Bemühen Sie sich um prägnante, modulare Designs.
Sidecar -Container sollten als schlanke Einheiten mit eingeschränkten Funktionen konzipiert sein. Diese Einfachheit erleichtert die Wartung und ermöglicht eine rasche Fehlererkennung innerhalb der Pods. Wenn Sie sicherstellen, dass der Sidecar modular und übersichtlich bleibt, können Sie die Konkurrenz mit dem Hauptcontainer bezüglich Ressourcen vermeiden.
Achten Sie auf die Ressourcengrenzen.
Sidecar-Container dürfen den Hauptcontainer hinsichtlich des Ressourcenverbrauchs nicht in den Schatten stellen. Sie sind in erster Linie dazu da, die Funktionen des Hauptcontainers zu erweitern oder zu ergänzen und spielen eine unterstützende Rolle. Während ihr kompaktes Design das Risiko eines übermäßigen Ressourcenverbrauchs minimieren kann, ist die Festlegung von Grenzen für ihren Ressourcenzugriff ebenso wichtig. Wenn Sidecars unkontrolliert Ressourcen verbrauchen, insbesondere Speicher, kann dies die Leistung Ihres Kubernetes-Clusters beeinträchtigen.
Ein mögliches Problem ist eine unzureichende Anzahl von Pods zur Verwaltung von Arbeitslasten. Wenn der Speicher eines Knotens im Cluster erschöpft ist, beendet der Systemkernel umgehend den speicherintensivsten Container, was zu einem OOM-Fehler (Out-of-Memory) und in der Regel zu einem beendeten Pod. Wenn Sie Ihr Sidecar richtig konfigurieren, können Sie spezifische Ressourcenlimits festlegen und dieses Problem umgehen.
Fazit
Obwohl dies ein legitimer Ansatz ist, können Sidecar-Container die Komplexität von Kubernetes-Clustern noch weiter erhöhen, was nicht nur die Verwaltung erschwert, sondern auch die Entdeckung von Kompromittierungen. Es ist wichtig, Ihre Sidecar-Container wie jeden anderen Container im Cluster zu behandeln und ihre Aktivitäten auf verdächtiges oder bösartiges Verhalten zu überwachen. Wir empfehlen die Erstellung eines neuen MITRE ATT&CK für die Sidecar-Injection-Container-Technik, um sich speziell auf diese Methode zu konzentrieren.