Kubernetes-Umgebungen sichern
Container-Vorteile nicht verspielen
Im März dieses Jahres trat mit Siloscape die erste ernsthafte Malware für Kubernetes (K8s) in Erscheinung. Dies untersteicht einmal mehr den Trend: Sobald eine Plattform an Relevanz gewinnt, tauchen für diese Schadcodes auf. Für Unternehmen stellt sich an dieser Stelle die Frage, wie sich Kubernetes-Umgebungen und die Container-Daten sichern lassen. Darüber hinaus ist entscheidend, was das Backup und die Wiederherstellung bei den diversen Distributionen leisten müssen, um die Vorteile von Kubernetes nicht zu verspielen.
Der Schadcode Siloscape, den das Team von Unit42 entdeckt hat, operiert ausschließlich aus einem Container heraus und zielt auf Hintertüren in schlecht konfigurierten Kubernetes-Clustern ab. Die Malware sammelt Daten auf Cluster-Ebene und erhält so Details zu gehosteten Datenbanken, Benutzeranmelde-Informationen und anderen geschäftskritischen Daten. So kann Ransomware diese Daten verschlüsseln. und dies wiederum kann zu einem Totalausfall führen.
Die Attacke verdeutlicht zwei Trends: Die Angreifer suchen erstens gezielt nach Schwachstellen im Code, und zweitens nutzen sie aus Security-Sicht schwache Konfigurationen der Kubernetes-Umgebungen aus.
Beides sind Faktoren, die künftig noch mehr Relevanz haben werden, da Entwicklerteams diesbezüglich noch Erfahrungen sammeln müssen.
Eine robuste Plattform gewinnt ihre Stärke, indem sich Benutzer an wichtige Regeln halten. Im Fall von Kubernetes bedeutet es, zu verstehen, wie sich das System von oben nach unten sichern lassen kann. Wer die Daten in einer Kubernetes-Umgebung schützen und die Auswirkungen menschlicher Fehler, Manipulationen oder von systembedingten Einflüssen eindämmen will, sollte die Systeme per Backup sichern. Aber die Struktur, Architektur und der Ansatz der Portabilität von Kubernetes verlangen nach einem speziell integrierten Ansatz für die Datensicherungs- und Wiederherstellungsstrategie.
Der Struktur entsprechend
Kubernetes-Plattformen arbeiten auf Basis eines Master-Worker-Modells, das sich hierarchisch aus mehreren Worker-Nodes und an der Spitze dem Cluster-Master-Node zusammensetzt. Die Kommunikation zwischen dem Master und den einzelnen Worker-Nodes ist über definierte Prozesse abgewickelt, die in jeder Distribution enthalten sind. Mit ihnen geschieht die gesamte Orchestrierung der Namespaces, Pods beziehungsweise Container. Namespaces lassen sich mit Persistent Storage Volumes, also festem Speicherplatz verknüpfen. Das ist wichtig, wenn in der Applikationsarchitektur Datenbanken wie MongoDB eingebunden sind. Auf diese Weise entscheidet sich, welche Elemente per Backup gesichert sein sollen. Der Master und die prozessgetriebene automatisierte Kubernetes-Orchestrierung legen den Grundstein für Cloud-native Anwendungen, die im Idealfall auf Micro-Service-Architekturen basieren. Durch die Container-basierte Architekturplattform lassen sich persistente und nicht-persistente Daten voneinander trennen und im Sinne der Applikationsarchitektur bestmöglich nutzen. So gestaltet sich das Einspielen von Updates wesentlich schneller und unter minimalen Betriebsunterbrechungen. Die Architektur ist in sich redundant ausgelegt, da die Worker-Nodes Lasten per Load Balancing untereinander dynamisch verteilen und per Failover an redundante Pendants umleiten. Außerdem lassen sich unter Berücksichtigung einheitlicher Standards Elemente von einer Cloud in eine andere Cloud-Umgebung verschieben.
- Container-Vorteile nicht verspielen
- Was und wie sichern?
Lesen Sie mehr zum Thema
