Hinweis perev. : Der Originalartikel wurde von einem schwedischen Ingenieur verfasst - Christian Abdelmassih, der Architektur, IT-Sicherheit und Cloud Computing auf Unternehmensebene mag. Kürzlich erhielt er einen Master-Abschluss in Informatik und hat es eilig, seine Arbeit zu teilen - eine Masterarbeit oder vielmehr ein Teil davon, die sich mit den Problemen der Isolierung einer containerisierten [und in Kubernetes gestarteten] Anwendung befasst. Als "Klient", für den diese Forschungsarbeit vorbereitet wurde, handelt nicht weniger als die Polizei seines Heimatlandes.
Container Orchestration und Cloud-Native Computing sind in den letzten Jahren sehr beliebt geworden. Ihre Anpassung hat ein derartiges Niveau erreicht, dass auch Finanzunternehmen, Banken und der öffentliche Sektor Interesse an ihnen zeigen. Sie zeichnen sich im Vergleich zu anderen Unternehmen durch umfangreiche Anforderungen im Bereich Informationssicherheit und IT aus.
Einer der wichtigen Aspekte ist, wie Container in Produktionsumgebungen verwendet werden können und gleichzeitig die Systemtrennung zwischen Anwendungen aufrechterhalten werden kann. Da solche Organisationen private Cloud-Umgebungen verwenden, die auf Virtualisierung auf Bare-Metal-Basis basieren, ist der Verlust einer solchen Isolation bei der Migration in eine Umgebung mit orchestrierten Containern nicht akzeptabel. Angesichts dieser Einschränkungen wurde meine Dissertation verfasst und die schwedische Polizei gilt als Zielgruppe.
Das spezifische Thema der in der Arbeit berücksichtigten Studie ist:
Wie wird die Anwendungsabgrenzung in Docker und Kubernetes im Vergleich zu virtuellen Maschinen unterstützt, die auf dem ESXi-Hypervisor ausgeführt werden, der auf Bare Metal ausgeführt wird?
Dieses Problem erfordert eine sorgfältige Untersuchung. Schauen Sie sich zunächst den gemeinsamen Nenner an - Anwendungen.
Webanwendungen sind verwirrend
Sicherheitslücken in Webanwendungen - ein echter Zoo von Angriffsmethoden. Die wichtigsten Risiken sind in den OWASP Top 10 (
2013 ,
2017 ) dargestellt. Diese Ressourcen helfen Entwicklern dabei, typische Risiken zu reduzieren. Selbst wenn die Entwickler fehlerfreien Code geschrieben haben, kann die Anwendung dennoch anfällig sein - beispielsweise durch Paketabhängigkeiten.
David Gilbertson hat eine
großartige Geschichte darüber geschrieben, wie Sie Code über ein schädliches Paket einfügen können, das beispielsweise als Teil von NPM für Node.js-basierte Anwendungen verteilt wird. Um Schwachstellen zu erkennen, können Sie Abhängigkeitsscanner verwenden,
die das Risiko jedoch nur
verringern , aber nicht vollständig beseitigen.
Selbst wenn Sie Anwendungen ohne Abhängigkeiten von Drittanbietern erstellen, ist es immer noch unrealistisch zu glauben, dass die Anwendung niemals anfällig wird.
Aufgrund dieser Risiken können wir nicht sagen, dass Webanwendungen sicher sind.Halten Sie sich stattdessen an eine Strategie der
Tiefenverteidigung (DID). Werfen wir einen Blick auf die nächste Ebene: Container und virtuelle Maschinen.
Container versus virtuelle Maschinen - eine Geschichte der Isolation
Ein Container ist eine isolierte User-Space-Umgebung, die häufig mithilfe der Funktionen des Kernels implementiert wird.
Docker verwendet hierfür beispielsweise die Linux-Namespaces, cgroups und -Funktionen. In diesem Sinne unterscheidet sich die Isolierung von Docker-Containern
stark von virtuellen Maschinen, die von Hypervisoren des Typs 1 gestartet werden
(d. H. Direkt auf Hardware arbeiten; Bare-Metal-Hypervisoren) .
Die Differenzierung für solche virtuellen Maschinen kann auf einem so niedrigen Niveau wie bei realer Hardware beispielsweise über
Intel VT implementiert werden. Docker-Container wiederum verlassen sich zur Abgrenzung auf den Linux-Kernel. Dieser Unterschied ist sehr wichtig, wenn es um
Layer-Under-Angriffe geht .
Wenn ein Angreifer in der Lage ist, Code in einer virtuellen Maschine oder einem Container auszuführen, kann er möglicherweise durch Ausführen eines
Fluchtangriffs auf eine niedrigere Ebene gelangen.
Abhängig davon, ob Container oder virtuelle Maschinen auf Hardware verwendet werden, wird die Differenzierung auf verschiedenen Infrastrukturebenen implementiert.Die Möglichkeit solcher Angriffe wurde für den
VMware ESXi- Hypervisor während des Pwn2Own 2017-Hacker-Wettbewerbs sowie für GeekPwn2018 nachgewiesen. Das Ergebnis war ein Paar
CVEs (
CVE-2017–4902 ,
CVE-2018–6981 ), die bei Layer-
under -Angriffen zum
Beenden virtueller Maschinen verwendet werden können ( Escape Virtual Machine ) . Virtuelle Maschinen auf Eisenservern garantieren keine absolute Sicherheit, obwohl sie Technologie verwenden, um den Eisengehalt zu differenzieren.
Wenn wir uns andererseits Angriffsvektoren auf einem Bare-Metal-Hypervisor im Vergleich zum Linux-Kernel ansehen, ist es offensichtlich, dass dieser eine viel größere Angriffsfläche hat - aufgrund seiner Größe und seines Funktionsumfangs [Linux-Kernel]. Eine größere Angriffsfläche impliziert mehr potenzielle Angriffsvektoren für Cloud-Umgebungen unter Verwendung der Containerisolation. Dies zeigt sich in der wachsenden Aufmerksamkeit für
Container-Fluchtangriffe , die dank Kernel-Exploits möglich wurden (z. B.
CVE-2016–5195 [dh Dirty COW - ca. übersetzt] ,
CVE-2017–1000405) )
Module wie
SELinux oder
AppArmor können verwendet werden, um die Isolierung
im Behälter zu erhöhen. Leider verhindern solche Sicherheitsmechanismen im Kernel keine Fluchtangriffe auf den Kernel selbst. Sie begrenzen die möglichen Aktionen des Angreifers nur, wenn ein Überschreiten der Grenzen
nicht möglich ist . Wenn wir uns mit Ausgängen außerhalb des Containers befassen möchten, wird ein Isolationsmechanismus
außerhalb des Containers oder sogar des Kerns benötigt. Zum Beispiel eine Sandbox
(Sandbox) !
gVisor ist eine Sandbox für die Container-
Laufzeit , deren Code von Google geöffnet wurde und die einen zusätzlichen Kernel zwischen dem Container und dem Kernel des Betriebssystems hinzufügt. Diese Art von Sandbox kann die Situation durch nicht gebundene Containerangriffe verbessern, die
auf Kernelebene stattfinden . Kern-Exploits sind jedoch nur eines der Werkzeuge des Angreifers.
Um zu sehen, wie andere Angriffe zu ähnlichen Ergebnissen führen können, müssen Sie sich ein allgemeineres Bild davon machen, wie Container in der Cloud-Native-Ära verwendet werden.
Die Auswirkung der Container-Orchestrierung auf die Isolation
Um Container zu verwalten, die in Umgebungen mit vielen Knoten ausgeführt werden, führen sie die Orchestrierung ein, in der Kubernetes die führende Rolle spielen. Wie sich herausstellt, können Orchestrator-Fehler auch die Containerisolation beeinflussen.
Tim Allclair hielt auf der KubeCon 2018 eine wundervolle Präsentation, in der er einige Angriffsflächen feststellte. In seinem Bericht
erwähnt er ein Beispiel (
CVE-2017-1002101 ), wie Orchestrierungsfehler die Isolation beeinflussen können - in diesem Fall durch die Möglichkeit, Speicherplatz außerhalb des Pods
bereitzustellen . Sicherheitslücken dieser Art sind sehr problematisch, weil kann den Sandkasten umgehen, in den der Behälter eingewickelt ist.
Durch die Einführung von Kubernetes haben wir die Angriffsfläche erweitert. Es enthält Systeme, die auf dem Kubernetes-Master gehostet werden. Einer davon ist der Kubernetes-API-Server, auf dem kürzlich eine Sicherheitsanfälligkeit entdeckt wurde, die
übermäßige Berechtigungen zulassen könnte (
CVE-2018–1002105 ). Da die Angriffsfläche des Kubernetes-Masters den Rahmen meiner Dissertation sprengt, wird diese besondere Sicherheitsanfälligkeit nicht berücksichtigt.
Warum sind Fluchtangriffe so wichtig? Container boten die Möglichkeit, viele gemeinsam gehostete Anwendungen unter demselben Betriebssystem auszuführen. Mit der Anwendungsisolation war also ein Risiko verbunden. Wenn eine geschäftskritische Anwendung und eine andere anfällige Anwendung auf demselben Host ausgeführt werden, kann ein Angreifer durch einen Angriff auf eine anfällige Anwendung Zugriff auf eine kritische Anwendung erhalten.
Abhängig davon, mit welcher Art von Daten die Organisation arbeitet, kann ihr Leck nicht nur der Organisation selbst, sondern auch Einzelpersonen und dem gesamten Land schaden. Wie Sie sich erinnern, sprechen wir über den öffentlichen Sektor, Finanzen, Banken ... - ein Leck kann das Leben der Menschen ernsthaft beeinträchtigen.
Kann die Container-Orchestrierung in solchen Umgebungen überhaupt verwendet werden? Vor weiteren Überlegungen muss eine Risikobewertung durchgeführt werden.
Welches Risiko ist akzeptabel?
Vor der Einführung von Sicherheitsmaßnahmen ist es wichtig zu überlegen, welche Art von Informationen das Unternehmen tatsächlich zu schützen versucht. Die Entscheidung, ob weitere Schritte erforderlich sind, um mögliche Fluchtangriffe auf Container zu verhindern, hängt von den Daten ab, mit denen die Organisation arbeitet, und von den von ihr bereitgestellten Diensten.
Langfristig bedeutet dies, dass der Angreifer: Um die Möglichkeit zu erreichen, den Container auf einem
korrekt konfigurierten Host zu verlassen, der durch die Sandbox für den Container geschützt ist, muss er:
- Code in einem Container ausführen, z. B. durch Code-Injection oder Verwendung von Schwachstellen im Anwendungscode;
- Nutzen Sie eine andere Sicherheitsanfälligkeit, Zero-Day, oder für die noch kein Patch angewendet wurde, um den Container zu verlassen, obwohl eine Sandbox vorhanden ist .
Wie Sie vielleicht erraten haben, sollte eine Organisation, die ein solches Szenario nicht für akzeptabel hält, mit Daten arbeiten oder Dienste anbieten, die hohe Anforderungen an
Vertraulichkeit ,
Integrität und / oder
Zugänglichkeit stellen .
Da die Dissertation nur solchen Kunden gewidmet ist, ist der Verlust der Systemisolation durch Verlassen des Containers nicht zulässig, da seine Folgen sind zu bedeutend. Welche Schritte können unternommen werden, um die Isolation zu verbessern? Um eine Ebene in der Isolationsleiter nach oben zu gelangen, sollten Sie sich auch die Sandboxen ansehen, in die der Betriebssystemkern eingeschlossen ist, d. H. virtuelle Maschinen!
Virtualisierungstechnologien, die gehostete Hypervisoren verwenden, werden die Situation verbessern, aber wir möchten die Angriffsfläche
noch weiter einschränken. Lassen Sie uns daher die auf Eisen installierten Hypervisoren untersuchen und herausfinden, wohin sie uns führen werden.
Hypervisoren auf Eisen
Eine
Studie der schwedisch-schwedischen Verteidigungsforschungsagentur untersuchte die Risiken der Virtualisierung in Bezug auf die schwedischen Streitkräfte. Seine Schlussfolgerung sprach von den Vorteilen dieser Technologien für das Militär, selbst bei den strengen Sicherheitsanforderungen und Risiken, die die Virtualisierung mit sich bringt.
In diesem Zusammenhang können wir sagen, dass Virtualisierung (bis zu einem gewissen Grad) in der Verteidigungsindustrie eingesetzt wird, da sie
akzeptable Risiken birgt. Da Agenturen und Unternehmen in der Verteidigungsindustrie einer der anspruchsvollsten Kunden für IT-Sicherheit sind, können wir auch argumentieren, dass das akzeptable Risiko für sie bedeutet, dass es für die in der Dissertation berücksichtigten Kunden akzeptabel ist. Und das alles - trotz der oben beschriebenen potenziellen Exits jenseits der virtuellen Maschine.
Wenn wir uns entscheiden, diese Art von Sandbox für Container zu verwenden, sind im Zusammenhang mit Cloud-nativen Besonderheiten einige Dinge zu beachten.
Sandbox-Knoten für virtuelle Maschinen
Die Idee ist, dass die Knoten des Kubernetes-Clusters virtuelle Maschinen sind, die Hardwarevirtualisierung verwenden. Da virtuelle Maschinen die Rolle von Sandboxen für Container spielen, die in Pods ausgeführt werden, kann jeder Knoten als sandboxgeschützte Umgebung betrachtet werden.
Ein wichtiger Hinweis zu diesen Sandboxen im Zusammenhang mit den bereits erwähnten Containersandboxen: Mit diesem Ansatz können Sie viele Container in einer Sandbox platzieren. Diese Flexibilität ermöglicht es Ihnen, den Overhead im Vergleich zu dem Fall zu reduzieren, in dem jeder Container über eine eigene Sandbox verfügt. Da jede Sandbox ein eigenes Betriebssystem hat, möchten wir ihre Anzahl reduzieren und gleichzeitig die Isolation beibehalten.
Auf der Hardware installierte virtuelle Maschinen - Clusterknoten - fungieren als Sandboxen für Container. Container, die auf verschiedenen VMs ausgeführt werden, sind mit einem akzeptablen Risiko begrenzt. Dies gilt jedoch nicht für Container, die auf derselben VM ausgeführt werden.Da Kubernetes jedoch aus verschiedenen Gründen die Platzierung von Pods ändern kann, was
die Idee der Verwendung von Sandboxen ruinieren kann, müssen Einschränkungen für den Mechanismus zum Teilen von Pods hinzugefügt werden. Sie können das gewünschte auf viele Arten erreichen.
Zum Zeitpunkt des Schreibens unterstützt Kubernetes (
v1.13 ) drei Hauptmethoden zur Steuerung der Planung und / oder des Starts von Pods:
Welche Methode (n) verwendet werden soll (n), hängt von der Anwendung der Organisation ab. Es ist jedoch wichtig zu beachten, dass sich Methoden in ihrer Fähigkeit unterscheiden, Pods nach Eintritt in die Ausführungsphase zu verwerfen. Jetzt sind nur noch Taints dazu in der Lage - durch die
NoExecute Aktion. Wenn Sie diesen Moment in keiner Weise verarbeiten und sich einige Etiketten ändern, kann alles zu einer unerwünschten Kollokation führen.
Einhaltung der Co-Location-Anforderungen
In der Dissertation wird die Idee vorgeschlagen, ein Klassifizierungssystem zu verwenden, das zeigt, wie sich die Empfindlichkeit in der Kollokation widerspiegelt. Die Idee ist, die 1: 1-Beziehung zwischen dem Container und dem Pod zu verwenden und die Kollokation der Pods basierend auf der Klassifizierung von Containeranwendungen zu bestimmen.
Zur Vereinfachung und Wiederverwendbarkeit wird das folgende dreistufige Klassifizierungssystem verwendet:
- Klasse O : Die Anwendung ist nicht empfindlich und hat keine Isolationsanforderungen. Es kann auf allen Knoten platziert werden, die nicht zu anderen Klassen gehören.
- Klasse PG (private Gruppe) : Eine Anwendung bildet zusammen mit einer Reihe anderer Anwendungen eine private Gruppe, für die ein dedizierter Knoten erforderlich ist. Eine Anwendung kann nur auf PG-Klassenknoten gehostet werden, die die entsprechende private Gruppen-ID haben.
- Klasse P (privat) : Eine Anwendung benötigt einen privaten und separaten Knoten und kann nur auf leeren Knoten ihrer Klasse (P) platziert werden.
Um die Anforderungen der Kollokation für viele klassifizierte Anwendungen zu erfüllen, werden Verschmutzungen und Toleranzen verwendet, denen jeder Knoten eine Klasse zugewiesen ist, und PodAffinity, um zusätzliche Einschränkungen für Pods mit Anwendungen der Klasse P oder PG anzuwenden.
Dieses vereinfachte Beispiel zeigt, wie Verschmutzungen und Toleranzen verwendet werden können, um die Kollokationskontrolle zu implementieren:
Pods 2 und 3 enthalten Anwendungen aus einer privaten Gruppe, und die Anwendung auf Pod 1 ist sensibler und erfordert einen dedizierten Knoten.Für die P- und PG-Klassen sind jedoch zusätzliche Affinitätsregeln erforderlich, um sicherzustellen, dass Abgrenzungsanforderungen ausgeführt werden, wenn der Cluster und die gehosteten Anwendungen wachsen. Mal sehen, wie Sie
diese Regeln für verschiedene Klassen implementieren können:
# Class P affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" namespaces: ["default"] labelSelector: matchExpressions: - key: non-existing-key operator: DoesNotExist
Affinitätsregeln für Anwendungen der Klasse P erfordern dedizierte Knoten. In diesem Fall wird der Pod nicht geplant, wenn der Pod ohne
non-existing-key . Alles wird funktionieren, bis ein einzelner Pod diesen Schlüssel hat.
# Class PG affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchLabels: class-pg-group-1: foobar podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: - key: class-pg-group-1 operator: DoesNotExist
Bei Anwendungen der PG-Klasse werden Affinitätsregeln Pods mit einer
class-pg-group-1 und Knoten mit Pods ohne eine ID gemeinsam hosten.
Ein solcher Ansatz ermöglicht es uns, mithilfe eines Klassifizierungssystems Container auf der Grundlage der relevanten Anforderungen einer containerisierten Anwendung abzugrenzen.
Was haben wir bekommen?
Fazit
Wir haben eine Möglichkeit in Betracht gezogen, Sandboxen basierend auf einem Hypervisor vom Typ 1 (d. H. Auf Bare-Metal-Basis gestartet) zu implementieren, um Knoten in Kubernetes-Clustern zu erstellen, und ein Klassifizierungssystem vorgestellt, das die Anforderungen für die Abgrenzung containerisierter Anwendungen definiert. Wenn wir diesen Ansatz mit den anderen betrachteten Lösungen vergleichen, hat er Vorteile hinsichtlich der Gewährleistung der Systemisolation.
Eine wichtige Schlussfolgerung ist, dass die Isolationsstrategie
die Ausbreitung von Fluchtangriffen auf den Container
einschränkt .
Mit anderen Worten, das Verlassen des Behälters allein wird nicht verhindert, aber seine Auswirkungen werden gemindert. Dies bringt natürlich zusätzliche Schwierigkeiten mit sich, die bei ähnlichen Vergleichen berücksichtigt werden müssen.
Um die angegebene Methode in einer Cloud-Umgebung zu verwenden und Skalierbarkeit bereitzustellen, werden zusätzliche Anforderungen an die Automatisierung gestellt. Zum Beispiel, um die Erstellung virtueller Maschinen und deren Verwendung im Kubernetes-Cluster zu automatisieren. Das Wichtigste wird die Implementierung und Überprüfung der
weit verbreiteten Klassifizierung von Anwendungen sein.
Dies ist Teil meiner Dissertation über die
Isolierung einer containerisierten Anwendung .
Um zu verhindern, dass ein Angreifer, der sich auf einem Knoten vom Container abgemeldet hat, die Dienste anderer Knoten
angreift , müssen
netzwerkverbreitete Angriffe berücksichtigt
werden . Um diesen Risiken Rechnung zu tragen, schlägt meine Dissertation die
Segmentierung des Clusternetzwerks vor und führt Cloud-Architekturen ein, von denen eine über eine
Hardware-Firewall verfügt .
Wer möchte, kann sich mit dem vollständigen Dokument vertraut machen - der Text der Dissertation ist öffentlich zugänglich: „
Container Orchestration in sicherheitsbedürftigen Umgebungen bei der schwedischen Polizeibehörde “.
PS vom Übersetzer
Lesen Sie auch in unserem Blog: