Geschrieben von: Yu Pengfei , Mah Chia Hui

Einführung

Das explosionsartige Wachstum der Kubernetes-Nutzung im letzten Jahrzehnt war ein riesiges Spektakel. Allerdings wurde Rom nicht an einem Tag erbaut, und wie bei jedem anderen großen Technologie-Stack, der heute im Einsatz ist, dauerte es mehrere Jahrzehnte, bis die Containerisierungstechnologie ausgereift war, bevor sich Kubernetes in seiner aktuellen Phase als die beste Artikulation erwies.

Da immer mehr Anwendungen in Containern abgelegt werden, erfreuen sich Orchestrierungs-Engines wie Kubernetes großer Beliebtheit. Als Orchestrierungs-Engine hilft Kubernetes bei der Verwaltung, Skalierung und Bereitstellung von Containeranwendungen. Allerdings gibt es unzählige verschiedene Orchestrierungs-Engines (z. B. Docker Swarm) – warum ist Kubernetes nach wie vor so beliebt? Eine schnelle Antwort liegt darin, dass Kubernetes reich an Funktionen ist und über Funktionen wie Selbstheilung und automatische Skalierung verfügt. Darüber hinaus wird Kubernetes von den meisten Cloud-Service-Providern (CSP) als Managed Service implementiert. Dies festigt seine Position als „Goldstandard“ für Orchestrierungs-Engines. Die Akzeptanz von Kubernetes nimmt weiter zu, wobei 96 % der Unternehmen Kubernetes nutzen oder evaluieren. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Mo' Honey Mo' Probleme

Angesichts der weit verbreiteten Nutzung von Kubernetes überrascht es nicht, dass es sich auch um eine wertvolle Angriffsfläche handelt, die Angreifer aktiv auszuspionieren und auszunutzen versuchen. Mit seinem neuen Aufstieg machen Entwickler auch Fehler bei der Implementierung, Konfiguration oder Bereitstellung.

Dieser Artikel ist der erste unserer Serie zum Thema Kubernetes-Sicherheit. Es bietet einen Überblick über einige häufige Angriffe und grundlegende Best Practices für die Sicherheit von Kubernetes. Nachfolgende Artikel werden tiefer auf komplexere Angriffe wie HostPath-Montage, Trampolin-Pods/Knoten usw. und deren Abhilfe eingehen.

Um die Angriffe zu verstehen, müssen wir zunächst die Kubernetes-Architektur verstehen. Das folgende allgemeine Diagramm ist ein guter Ausgangspunkt. Wenn Sie bereits mit der Kubernetes-Architektur und ihren Grundlagen vertraut sind, können Sie gerne mit „Angriffsmethodik“ fortfahren.

Kubernetes-Architekturdiagramm

Schoten

Kubernetes besteht aus vielen beweglichen Teilen und seine unterste Arbeitseinheit wird als POD bezeichnet . Ein Pod kann mehrere verschiedene Container und Speichervolumes beherbergen. Jeder Pod verfügt außerdem über eine eindeutige IP-Adresse. Es ist außerdem äußerst skalierbar, da es auf Bereitstellungsplänen (YAML-Datei) basiert.

Knoten

Um die Sache für alle einfach zu halten, unterteilen wir die Knotentypen wie folgt:

● Worker-Knoten

● Masterknoten

Eine Reihe von Knoten bildet einen Cluster.

Worker-Knoten:

Auf diesen Worker-Knoten befinden sich Pods, bei denen es sich entweder um virtuelle oder physische Maschinen handeln kann. Sie können sie sich als Host-Maschinen für Pods vorstellen.

Masterknoten:

Ein Masterknoten ist der ultimative Administrator des gesamten Clusters. Es steuert und verwaltet alle Worker-Knoten, zu denen die folgenden Komponenten gehören: Kube-API-Server, Kube-Controller-Manager, Kube-Scheduler usw.

Namensraum

Ein Kubernetes-Namespace ist ein Isolationsmechanismus, der Ressourcen innerhalb eines Clusters isoliert und im Allgemeinen verwendet wird, wenn verschiedene Teams an demselben Cluster arbeiten. Im Cybersicherheitskontext ist jedes Namespace-Objekt/jede Namespace-Ressource für den Namespace einzigartig. Ein namensraumübergreifender Aufruf von Objekten/Ressourcen ist nicht möglich, da diese Objekte/Ressourcen innerhalb ihrer Namensräume isoliert sind.

Mit all diesem neuen Wissen sollten Sie nun über ein grundlegendes Verständnis der Kubernetes-Umgebung verfügen. Kommen wir zur saftigeren Seite der Dinge: Wie greift man Kubernetes an?

Angriffsmethodik

Die Vorgehensweise eines ausgefeilten Angreifers kann in drei Phasen unterteilt werden.

Stufe 1: Erster Halt

Der erste Weg, Fuß zu fassen, besteht darin, eine im Cluster gehostete Webanwendung oder einen Microservice zu kompromittieren. Das Ziel des Angreifers besteht darin, eine Remote-Codeausführung für die Anwendung zu erreichen, indem er die Anwendung auflistet und ausnutzbare Schwachstellen identifiziert (z. B. log4shell, Apache Struts).

Stufe 2: Privilegieneskalation

Wenn ein Angreifer im Kubernetes-Cluster Fuß fasst, befindet er sich in einem Pod, bei dem es sich, wie erläutert, lediglich um einen Docker-Container handelt. Ein Angreifer könnte den Container nach sensiblen Daten ausspionieren, ist jedoch auf die verfügbaren Daten beschränkt. . Daher wird der Angreifer versuchen, entweder zu einem Pod mit mehr Privilegien oder zu einem Knoten zu eskalieren.

Im Folgenden sind einige gängige Techniken aufgeführt, die ein Angreifer anwenden würde:

• Sensible Dateien

Abhilfe:

Zusätzlich zur Standardpraxis, vertrauliche Anmeldeinformationen nicht unverschlüsselt in einem Pod zu belassen, sollte sich ein Kubernetes-Administrator bei der Bereitstellung von Berechtigungen für das Dienstkonto-Token an die Grundsätze der geringsten Rechte halten.

• Erreichbare Anwendungen

Abhilfe:

Um zu verwalten, welche Pods, Namespaces oder sogar externe Server eine bestimmte Kubernetes-Ressource erreichen können, kann ein Kubernetes-Administrator die Kubernetes-Netzwerkrichtlinienressource verwenden .

• Cloud-Metadatendienste

Abhilfe:

Der Kubernetes-Administrator kann die oben genannte Kubernetes-Netzwerkrichtlinienressource nutzen , um einen Angreifer daran zu hindern, die Cloud-Metadaten-API und andere im Cluster gehostete Anwendungen zu erreichen, die nicht für Kerngeschäftsfunktionen erforderlich sind.

• Pod-Ausbruch

Abhilfe:

Der Kubernetes-Administrator kann die Admission Controller-Ressource verwenden, eine Kubernetes-Ressource, die jede im Kubernetes-Cluster erstellte Ressource anhand eines definierten Regelsatzes validiert. Eine Ressource, die nicht dem definierten Regelsatz entspricht, kann nicht erstellt werden, was zu einem Fehler führt.

Stufe 3: Erhalt der Kronjuwelen

Im Kubernetes-Ökosystem beziehen sich die Kronjuwelen auf den Masterknoten. Ein Angreifer, der vollen Zugriff auf den Masterknoten erlangt hat, hätte im Wesentlichen die vollständige Kontrolle über den Kubernetes-Cluster. Der Angreifer würde die in den Stufen 1 und 2 beschriebenen Techniken wiederholen, um seitlich von einem infizierten Pod zum darunter liegenden Knoten und schließlich zum Masterknoten zu gelangen. Um das Eintreten dieses Worst-Case-Szenarios zu verhindern, muss ein Kubernetes-Administrator sicherstellen, dass der Cluster mit einigen der oben genannten Abhilfemaßnahmen sicher konfiguriert ist.

Ist das alles?

Für einen umfassenderen Einblick in die Kubernetes-Sicherheitslage Ihres Unternehmens empfehlen wir die Nutzung der Kubernetes-Angriffsmatrix von Microsoft. Die Matrix umfasst wichtige Taktiken, die für die Kubernetes-Sicherheit relevant sind. Jeder von ihnen enthält mehrere Techniken, mit denen Angreifer unterschiedliche Ziele erreichen können.

Abschluss

Da immer mehr Unternehmen Kubernetes als De-facto-Tool zur Verwaltung der Container-Orchestrierung einsetzen, werden immer mehr sensible Daten in Kubernetes-Clustern landen. Es besteht ein noch größerer Bedarf für Systemadministratoren, die ihren Cluster so einrichten möchten, dass er sicher konfiguriert wird. Ein Angreifer mit vollem Zugriff auf den Masterknoten eines Kubernetes-Clusters ist das Letzte, was ein CISO sehen möchte.

Achten Sie auf unsere kommenden Artikel, in denen wir ausführlichere und spezifischere Angriffe vorstellen, die wir heute häufig in diesem Bereich sehen.

Pass auf dich auf und erwisch dich auf dem FLIPPETY-FLIP.