Mögliche Angriffsziele, mitigierende Maßnahmen und sinnvolle Prüfziele: Kubernetes sicher betreiben
Kubernetes ist eine Open-Source-Plattform zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Neben den vielen Vorteilen wie Ressourcenmanagement, effiziente Ressourcennutzung und Ausfallsicherheit gibt es auch Herausforderungen, besonders für den sicheren Betrieb.
Welchen Angriffen sind Kubernetes-Umgebungen ausgesetzt und wie lassen sie sich schützen? Welche Angriffsziele sollten mit welcher Priorität näher betrachtet werden?
Ein Kubernetes-Cluster besteht aus verschiedenen Komponenten und Diensten, die zusammenarbeiten, um containerisierte Anwendungen zu verwalten und bereitzustellen. Das Cluster steht dabei nicht für sich allein, sondern ist in der Regel in eine komplexe und hochautomatisierte Entwicklungs-und Produktionsumgebung eingebettet. Die wichtigsten Angriffsziele in einer Kubernetes-Umgebung sind die Deployment-Pipeline, die Image-Registry, die Control-Plane/das Cluster, die Worker-Nodes sowie die Anwendungen, die auf dem Kubernetes-Cluster laufen.
Deployment-Pipeline
Die Deployment-Pipeline ist der Prozess, in dem normalerweise der Anwendungscode von Entwicklern getestet und in produktionsbereite Container-Images umgewandelt wird. Anschließend können diese auf einem Kubernetes-Cluster bereitgestellt werden. Ein potenzieller Angreifer kann hier ansetzen und beispielweise versuchen, Schwachstellen im Build-Service oder der zugehörigen Zugangsverwaltung auszunutzen, um Schadcode einzuschleusen oder die Integrität der bereitgestellten Anwendungen zu gefährden.
Letztlich ist eine Build-Pipeline nichts anderes als Reihe von Skripten und Abhängigkeiten. Gelingt es Angreifern, Skripte zu verfälschen oder vollständig auszutauschen, können diese Schadcode in die Anwendung einbringen. Alternativ manipulieren Aggressoren Abhängigkeiten der Build-Pipeline, sodass beispielsweise veralte Bibliotheken oder Versionen mit bekannten oder unbekannten Schwachstellen für den Bau des Container-Images verwendet werden. Beide Varianten zielen darauf ab, die Anwendung oder den Container zu kompromittieren, um Daten direkt abzugreifen oder um auf die dahinter liegenden Cluster-Ressourcen auszubrechen.
Angriffe auf die Deployment-Pipeline haben schwerwiegende Folgen, da sie die gesamte Lieferkette einer Anwendung beeinflussen. Im schlimmsten Fall kann ein Angreifer vollen Zugriff auf die Applikation, die verarbeiteten Daten und den Cluster selbst erlangen.
Prüfung der Deployment-Pipeline
Die Sicherheit der Deployment-Pipeline ist entscheidend, um zu gewährleisten, dass nur vertrauenswürdiger und geprüfter Code in den Produktionscluster gelangt. Genauso wichtig ist es, sicherzustellen, dass ein Angreifer die Abhängigkeiten und Skripte der Build-Pipeline nicht manipulieren kann. Der Build Service sollte einem Penetrationstest (Pentest) oder einem Konfigurationsreview unterzogen werden. Ebenso ist ein Prozessaudit der Entwicklungsprozesse sinnvoll.
Image-Registry
Die Image-Registry ist ein kritisches Element in der Lieferkette von Anwendungen. Sie ist ein zentrales Repository, in dem Container-Images gespeichert und verwaltet werden. Diese Images enthalten alle Komponenten, die zur Ausführung einer Anwendung erforderlich sind, einschließlich des Betriebssystems, der Anwendung und ihrer Abhängigkeiten. Entwickler können diese Container-Images aus öffentlichen Quellen – sogenannten Hubs – in eine interne Image-Registry hochladen oder direkt für den Deployment-Prozess verwenden. Sie können aber auch selbst ein neues Container-Image erstellen und in eine Image-Registry hochladen.
Angreifer könnten versuchen, Schwachstellen in der Image-Registry auszunutzen, um bösartige Images hochzuladen oder legitime Images zu manipulieren. Ein beliebter Angriffsvektor besteht zudem darin, schädliche Container-Images in öffentlichen Hubs zu platzieren. Diese sind mit den vom Entwickler erwarteten Funktionen ausgestattet und beschrieben, enthalten aber zusätzlich vom Angreifer eingebaute Schwachstellen, um Zugriff auf die Betriebsumgebung zu erlangen. Gleiche oder ähnliche Strategien werden vom Angreifer verwendet, wenn er die Möglichkeit hat, auf eine interne Image-Registry zuzugreifen. Es ist daher von entscheidender Bedeutung, die Integrität der Image-Registry sicherzustellen und die zulässigen Quellen für Container-Images einzuschränken.
Prüfung der Image-Registry
Auch bei der Image-Registry ist eine Prozess- und Konfigurationsüberprüfung der sinnvollste erste Schritt. Es muss sichergestellt sein, dass nur autorisierte Benutzer und Systeme auf die Registry zugreifen und Images hoch- oder herunterladen können. Das Einspielen neuer Images sollte mindestens durch ein Vier-Augen-Prinzip verifiziert und vor dem ersten Upload auf Schwachstellen und Malware überprüft werden. Zusätzlich sollte man die Images regelmäßig und automatisiert auf bekannte Sicherheitslücken und Malware kontrollieren.
Das Cluster: Control-Plane und Worker-Nodes
Die Control-Plane ist das Gehirn eines Kubernetes-Clusters. Sie umfasst Komponenten wie den API-Server, den Scheduler und den Controller-Manager, die für die Verwaltung des Clusters verantwortlich sind. Angriffe auf die Control-Plane können das gesamte Cluster destabilisieren oder zur vollständigen Übernahme führen. Angreifer können probieren, unberechtigten Zugriff auf den API-Server zu erlangen, um administrative Befehle auszuführen oder die Netzwerkkommunikation zu manipulieren. Ebenso kann versucht werden, auf Cluster-Ressourcen wie Persistent Volumes zuzugreifen, um auf diesem Weg an Daten zu gelangen. Auf der Control-Plane werden keine Anwendungen ausgeführt.
Sie dient lediglich der Verwaltung und Steuerung der Ressourcen, auf denen die Applikationen bereitgestellt werden. Diese Ressourcen werden Worker-Nodes genannt. Worker-Nodes sind die Maschinen, auf denen die Pods beziehungsweise Container ausgeführt werden. Sie stellen die Rechenleistung bereit, die erforderlich ist, um Anwendungen in einem Kubernetes-Cluster auszuführen. Angreifer nutzen Schwachstellen in den Worker-Nodes aus, um Zugriff auf die darunter liegenden Betriebssysteme zu erlangen, Container zu kompromittieren oder sensible Daten zu exfiltrieren. Die Sicherheit der Worker-Nodes ist entscheidend, um die Integrität der ausgeführten Anwendungen zu gewährleisten.
Schwachstellen in der Namespace-Konfiguration oder der Pod-Konfiguration sind mögliche Angriffsziele. Ähnlich wie bei Angriffen auf die Control-Plane oder Worker-Nodes ist das Ziel auch hier, unautorisierten Zugriff auf Ressourcen zu erlangen, die dem Angreifer einen möglichst umfassenden Datenzugriff ermöglichen.
Prüfung der Cluster-Sicherheit
Die Überprüfung der Clustersicherheit ist die komplexeste und damit auch aufwendigste Methode, um den sicheren Betrieb der Clusterumgebung zu gewährleisten. Verschiedene Konfigurationsdateien der Control-Plane und der Worker-Nodes müssen auf Betriebssystemebene auf Inhalt und Zugriffsberechtigungen überprüft werden. Zusätzlich müssen das Konzept und die Berechtigungen des clusterinternen RBAC und der Namespace-Konfiguration berücksichtigt werden.
Mögliche Prüfverfahren sind automatisierte Tests mit speziellen Test-Pods/-Containern oder ein Konfigurationsaudit des Clusters. Beide Verfahren ergänzen sich und bieten in Kombination eine aussagekräftige Analyse der Clustersicherheit.
Anwendungen
Die in Kubernetes bereitgestellten Anwendungen sind häufig selbst Angriffsziele. Schwachstellen in der Anwendungslogik, unsichere Konfigurationen oder veraltete Bibliotheken können von Angreifern ausgenutzt werden, um unbefugten Zugriff zu erlangen oder die Anwendung zu stören.
Ein Cyberkrimineller kann probieren, aus einer der Anwendungen auszubrechen. Gelingt dies, befindet sich der Angreifer auf der Virtualisierungsebene (dem Container) und kann von dort aus versuchen, die darunter liegenden Ressourcen zu kompromittieren. Da Kubernetes als Plattform zur Bereitstellung und Verwaltung von Anwendungen dient, ist es wichtig, dass die Applikationen selbst sicher sind und regelmäßig auf Schwachstellen überprüft werden.
Überprüfung der Anwendungen
Ein Pentest der in Kubernetes bereitgestellten Applikation ist notwendig, um sicherzustellen, dass die Anwendungen selbst sicher sind und es einem Angreifer nicht gelingen kann, aus der Anwendung auszubrechen. Der Betrieb einer Anwendung innerhalb eines Kubernetes-Clusters macht einen Pentest nicht obsolet. Ganz im Gegenteil: Empfehlenswert ist ein Grey- oder White-Box-Pentest. Der durchführende Analyst sollte aber wissen, dass die Anwendung in einem Kubernetes-Cluster betrieben wird.
Sinnvolle Prüfziele
Wie oben gezeigt, gibt es viele Auditziele, aber wo soll eine Organisation zuerst anfangen? Zeit, Personal und Budget sind in der Realität begrenzt. Unabhängig von den individuellen Gegebenheiten einer Organisation lassen sich folgende Faustregeln festhalten: Die aufwendige Überprüfung des Kubernetes-Clusters und seiner Worker-Nodes selbst ist vor allem dann sinnvoll, wenn der Kubernetes-Cluster eine sogenannte Multi-Tenant-Umgebung bereitstellt oder sich Assets mit unterschiedlichem Schutzbedarf in ein und demselben Cluster befinden. Kritische Assets, wie zum Beispiel eine PKI, sollten generell auf einem separaten System oder Cluster betrieben werden.
Vor einer Cluster-Überprüfung ist es in der Regel jedoch effektiver, sich zunächst auf die Sicherheitsprozesse rund um die Deployment-Pipeline, die Image-Registry und die Anwendungs-/Netzwerksicherheit zu konzentrieren. Kurz gesagt, die Wege zum Cluster sollten vorrangig abgesichert werden. Das Cluster beziehungsweise die Control-Plane und die Worker-Nodes sind üblicherweise für einen Angreifer nicht direkt erreichbar.
Der Weg zum Cluster ist lang und führt über die Deployment-Strecke, über einen Ausbruch aus der Anwendung oder das vorgelagerte Netzwerk. Die Netzwerksicherheit ist ein weiterer Bereich, der überprüft werden sollte, um einen sicheren Betrieb eines Kubernetes-Clusters zu gewährleisten. Ob ein klassischer Segmentierungs-Pentest inklusive Firewall-Überprüfung oder eine Konfigurationsanalyse der Public-Cloud-Umgebung notwendig ist, hängt immer von der im Einzelfall eingesetzten Technologie ab.
Fazit: Kubernates kann nur ganzheitlich sicher betrieben werden
Die Sicherheit eines Kubernetes-Clusters erfordert einen ganzheitlichen Blick auf alle Komponenten der Umgebung. Während die Überprüfung der Clusters-Konfiguration vor allem für Multi-Tenant-Umgebungen einen hohen Stellenwert hat, ist es im Standardbetrieb oft effektiver, sich zunächst auf die Sicherheitsprozesse rund um die Deployment-Pipeline und die Image-Registry zu konzentrieren. Durch die Implementierung robuster Zugriffskontrollen, regelmäßiger Sicherheitsscans und umfassender Überprüfungen können Organisationen sicherstellen, dass ihre Kubernetes-Umgebungen widerstandsfähig gegenüber Angriffen sind und die Integrität ihrer Anwendungen gewahrt bleibt. Ein Pentest der Anwendungen und ein Segmentierungstest des Netzwerks sind ebenfalls unerlässlich, um einen sicheren Betrieb der Kubernetes-Umgebung zu gewährleisten.
Phillip Ansorge ist Managing Consultant bei der usd AG. Mit über sechs Jahre Erfahrung in den Bereichen Informations- und IT-Sicherheit unterstützt er nationale und internationale Unternehmen dabei Cloud-Umgebungen sicher aufzubauen und zu betreiben.
Kubernetes-Grundlagen
Die klassische Virtualisierung ist inzwischen der Standard im modernen IT-Betrieb. Sie ermöglicht es, physische Ressourcen effizienter zu nutzen, die Flexibilität von Anwendungen und Ressourcen zu erhöhen und die Verwaltung von IT-Infrastrukturen zu vereinfachen. Virtualisierung ist eine Technologie, die es ermöglicht, mehrere virtuelle Maschinen (VMs) auf einer einzigen physischen Maschine (Host) auszuführen.
Jede virtuelle Maschine verhält sich wie ein eigenständiger Computer mit eigenem Betriebssystem (OS) und eigenen Anwendungen. Die Virtualisierung wird durch eine Software-Schicht ermöglicht, die als Hypervisor bezeichnet wird. Jede VM enthält ein vollständiges Betriebssystem und eine virtuelle Kopie der Hardware, die auf dem Hostsystem läuft.
Klassische Virtualisierung mithilfe von virtuellen Maschinen (VMs)
Dadurch ergibt sich bei der klassischen Virtualisierung mithilfe von Hypervisoren eine ineffiziente Ressourcennutzung, da für das Gast-OS viel CPU-Leistung, Hauptspeicher und Speicherplatz benötigt wird.
Docker
Um die Effizienz und Portabilität von Anwendungen zu verbessern, hat sich Docker als Lösung dieser Probleme etabliert. Docker ist eine Open-Source-Plattform, die es ermöglicht, Anwendungen in Container zu verpacken, zu verteilen und auszuführen. Ein Container ist eine standardisierte Einheit der Software, die alles enthält, was zum Ausführen einer Anwendung erforderlich ist, einschließlich Code, Laufzeit, Systemwerkzeuge, Bibliotheken und Einstellungen.
Container teilen sich denselben Kernel des Host-Betriebssystems und laufen als isolierte Prozesse im Userspace. Sie sind „leichter“ und starten schneller als VMs, da sie kein vollständiges Betriebssystem benötigen.
Klassische Virtualisierung mithilfe von Docker Engine und Containern
Kubernetes
Die Verwaltung vieler Container neigt allerdings zu einer gewissen Unübersichtlichkeit. Daher bildeten sich verschiedene Plattformen und Tools heraus, um die Handhabung von Containern zu erleichtern. Einer der bekanntesten Vertreter dafür ist Kubernetes.
Kubernetes ist eine Plattform zur Orchestrierung von Containern, die ursprünglich von Google entwickelt wurde. Sie automatisiert die Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Kubernetes verwaltet Container-Cluster, überwacht deren Zustand und verteilt den Netzwerkverkehr, um Anwendungen effizient und zuverlässig zu betreiben. Es ermöglicht eine einfache Verwaltung großer Container-Umgebungen und sorgt für hohe Verfügbarkeit und Skalierbarkeit der Anwendungen.
Ein Kubernetes-Cluster besteht immer aus einer Control-Plane – auch bekannt als Master – und einer Reihe von Worker-Nodes. Auf den Worker-Nodes werden Container bereitgestellt, in welchen die Anwendungen laufen. Die Kommunikation mit allen Cluster-Ressourcen und Anwendungen erfolgt ausschließlich über die Control-Plane.
Exemplarischer Aufbau eines Kubernetes-Clusters
