Die Kubernetes-Angriffsfläche

Erinnern Sie sich noch an die Zeiten, in denen Cybersicherheit einfach war? Das hat es nie gegeben. Aber auch wenn es schwer war, wussten wir, was wir tun mussten: welche Benutzerrechte riskant waren, wie man die Serverkommunikation schützen konnte usw. Es war nicht einfach, aber es war klar.

Mit der Einführung von Kubernetes fühlt sich die Sicherheit an wie das Navigieren auf einer unbekannten Karte. Wir haben keine Ahnung, worauf wir uns einlassen. Wie kann man Dinge sichern, die man nicht vollständig versteht? In diesem Blogbeitrag werden wir uns dieser Herausforderung stellen.

Dazu werden wir einen forschungsbasierten Ansatz wählen. Wir werden Fragen stellen und hoffen, dass die Antworten uns in eine Richtung führen, die uns hilft, die Technologie zu verstehen. Das macht die Kubernetes-Sicherheit nicht einfacher, aber überschaubarer. Tauchen wir also ein!

Was ist Kubernetes?

Kubernetes ist eine leistungsstarke Plattform für die Container-Orchestrierung, die für die effiziente Bereitstellung, Skalierung und Verwaltung von Anwendungen entwickelt wurde. Durch die Automatisierung der Verwaltung von containerisierten Anwendungen ermöglicht Kubernetes es Entwicklern, sich auf die Erstellung von Anwendungen zu konzentrieren, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen.

Kubernetes ist eine komplette Plattform, eine vollwertige Umgebung für die Verwaltung mehrerer Ressourcen. In diesem Blogbeitrag konzentrieren wir uns auf die Sicherheitsaspekte von zwei dieser Ressourcen:

Rollen und Pods

• Rollen – Durch die Definition von Rollen bietet Kubernetes eine fein abgestufte Zugriffskontrolle, die sicherstellt, dass Benutzer und Dienstkonten nur Aktionen ausführen können, für die sie berechtigt sind. Dies erhöht die Sicherheit und Integrität des Clusters. Wenn Benutzer- oder Dienstkonten mit privilegierten Rollen kompromittiert werden, können Angreifer Aktionen ausführen, zu denen sie nicht berechtigt sind, und so den Cluster gefährden.
• Pod – Als grundlegende Einheiten in Kubernetes ermöglichen Pods eine effiziente Container-Verwaltung. Sie vereinfachen die Bereitstellung, indem sie einen oder mehrere Container kapseln und dieselben Speicher- und Netzwerkressourcen gemeinsam nutzen. Dies erleichtert die Verwaltung von Anwendungskomponenten, die zusammenarbeiten müssen. Wenn Pods jedoch kompromittiert werden, können sie verwendet werden, um sich seitlich im Kubernetes-Cluster fortzubewegen und es in seiner Gesamtheit zu kompromittieren.

Die Bedeutung von Kubernetes

Laut der CNCF-Jahresumfrage 2022 ist die Sicherheit eine der beiden größten Herausforderungen bei der Verwendung und Bereitstellung von Containern. 40 % der Befragten, die Container für die meisten oder alle Produktionsanwendungen und Geschäftssegmente verwenden, geben an, dass Sicherheit für sie eine der größten Herausforderungen darstellt.

Die CNCF-Jahresumfrage 2023 ergab, dass 84 % der Befragten Kubernetes verwenden oder evaluieren, was seinen Status als Kerntechnologie untermauert. Für 40 % der Befragten ist die Sicherheit nach wie vor eine der größten Herausforderungen. Das bedeutet, dass es weltweit viel mehr Kubernetes-Cluster gibt, bei denen die Sicherheit weiterhin eine Herausforderung darstellt.

Warum entscheiden sich DevOps-Ingenieure und -Organisationen aus diesem Grund für Kubernetes? Der Grund ist, dass Kubernetes die Nutzung komplizierter Microservices-Architekturen in großem Maßstab unterstützt und gleichzeitig die Modularität und Verfügbarkeit von Diensten gewährleistet.

Die Angriffsfläche in Kubernetes

Mit zunehmender Systemkomplexität nimmt auch die Angriffsfläche zu. Kubernetes ist ein komplexes System. In den Augen des Angreifers umfasst die Kompromittierung von Kubernetes zwei Hauptaktionen: das Angreifen von Containern und das Vorankommen in Kubernetes.

Container:

• Container-Umgehung
  Dies geschieht, wenn ein Angreifer Schwachstellen im Kernel des Hosts, in der Container-Laufzeitumgebung oder in der containerisierten Anwendung ausnutzt, um aus dem Container auszubrechen und Zugriff auf das zugrundeliegende Host-System zu erlangen. Ein Container-Escape auf einem einzelnen containerisierten Server wäre schon schlimm genug, aber in einem größeren Kubernetes-Knoten könnte es das „Game Over“ für den gesamten Cluster bedeuten

Kubernetes:

• Seitliche Bewegung
  Sobald ein Angreifer innerhalb des Kubernetes-Clusters Fuß gefasst hat, kann er sich seitlich zu anderen Pods bewegen. Dies geschieht häufig durch Ausnutzung von Kubernetes-Rollenberechtigungen, schlecht konfigurierten Netzwerkrichtlinien oder Schwachstellen in den Kubernetes-Komponenten. Das Ausbrechen von Containern ist ein schwieriges Unterfangen für einen Angreifer, aber durch die Kombination von seitlichen Bewegungen im Cluster mit dem Zugriff auf Dienste, die oft lockerer konfiguriert sind, kann sich der Angreifer in einer besseren Position befinden, um das Ausbrechen von Containern zu ermöglichen.

• Eskalation von Privilegien
  Angreifer können Schwachstellen oder Fehlkonfigurationen ausnutzen, um ihre Privilegien innerhalb des Clusters zu erweitern. Dies kann dazu führen, dass sie die administrative Kontrolle über die Kubernetes-Kontrollebene erlangen und den gesamten Cluster kompromittieren.

Sowohl MITRE ATT&CK als auch Microsoft erkennen Kubernetes als eine umfassende Umgebung mit ihren eigenen, einzigartigen Sicherheitsherausforderungen und Angriffsvektoren an. Sie betonen die Notwendigkeit eines ganzheitlichen Sicherheitsansatzes, der das gesamte Ökosystem berücksichtigt, von der Container-Laufzeit über die Kubernetes-Kontrollebene bis hin zur zugrunde liegenden Infrastruktur.

 

Spotlight: Token für den Anwendungszugang

Betrachten wir zum Beispiel die Anwendungszugriffstoken. Jedes Mal, wenn ein Kubernetes-Pod mit einem Dienstkonto konfiguriert wird, fügt Kubernetes das Token des Dienstkontos in diesen Pod ein (sofern nicht anders konfiguriert). Das bedeutet, dass ein Angreifer, der Zugriff auf diesen Container hat, auch Zugriff auf das Token selbst erhält. Diese Token werden häufig für die Authentifizierung und Autorisierung von API-Aufrufen zwischen Microservices verwendet, wodurch Angreifer Zugriff auf sensible Ressourcen und Dienste erhalten. Nun kann der Angreifer mit einem kube-api-Server kommunizieren und seine nächsten Angriffsschritte durchführen.

Sind alle diese Token riskant? Nein, aber einige sind es.

Hier ist zum Beispiel ein Token, das geheime Berechtigungen auflistet. Ein Angreifer, der über diese Art von Berechtigungen verfügt, kann einfach nach dem Cluster-Admin-Token fragen. Damit ist das Spiel vorbei.

 

Es gibt andere, graue Bereiche. Auf diesem Bild sehen Sie, dass um die Erlaubnis gebeten wird, einen Pod zu erstellen. Ist das riskant?

 

Ich würde sagen, dass es definitiv so ist. Dafür gibt es zwei Hauptgründe:

1. Wenn Sie einen Pod konfigurieren, können Sie die auszuführenden Befehle auswählen.
2. Wenn Sie einen Pod konfigurieren, können Sie jedes beliebige Dienstkonto hinzufügen, das Sie haben möchten. Und schon ist das Spiel wieder vorbei.

Cloud vs. On-Prem Kubernetes-Lösungen

Control Plane Management: Cloud-Anbieter AKS, EKS, GKE

Wenn man Kubernetes-Lösungen in Betracht zieht, ist eine der wichtigsten Entscheidungen, ob man sich für einen Cloud-verwalteten Dienst wie Azure Kubernetes Service (AKS), Amazon EKS (EKS) oder Google Kubernetes Engine (GKE) usw. entscheidet oder ob man einen Kubernetes-Cluster selbst verwaltet (vor Ort oder in der Cloud). Cloud-Anbieter bieten verwaltete Kubernetes-Dienste an, die die Steuerungsebene verwalten, zu der Komponenten wie der API-Server, der Scheduler und der Controller-Manager gehören. Dadurch wird der betriebliche Aufwand auf den Cloud-Anbieter verlagert, so dass sich die Teams mehr auf die Anwendungsbereitstellung und weniger auf die Infrastrukturverwaltung konzentrieren können.

Im Gegensatz dazu müssen die Teams bei nativen Kubernetes-Bereitstellungen den gesamten Lebenszyklus des Kubernetes-Clusters verwalten, einschließlich Upgrades, Sicherheits-Patches und Skalierung. Dies gibt Unternehmen mehr Kontrolle über ihre Infrastruktur, erfordert jedoch erhebliche Fachkenntnisse und Ressourcen für eine effektive Wartung.

Risikokalkulation: Komplexität von Cloud und Kubernetes

Sowohl von der Cloud verwaltete als auch vor Ort installierte Kubernetes-Lösungen sind mit einer Reihe von Risiken und Komplexitäten verbunden. Cloud-verwaltete Dienste abstrahieren einen Großteil der zugrundeliegenden Infrastrukturverwaltung, was das Risiko von Fehlkonfigurationen oder veralteter Software verringern kann. Daher entscheiden sich Unternehmen in der Regel für eine Cloud-Lösung, weil sie sich nicht mit der Komplexität befassen wollen. Stattdessen wollen sie einfach nur, dass Kubernetes funktioniert.

Dennoch müssen Unternehmen die Risiken verstehen, die mit der Bereitstellung von Kubernetes in Cloud-Umgebungen verbunden sind.

AWS EKS Angriffsvektor: Ausnutzung von Berechtigungen

Ein Beispiel für das Risiko ist ein spezieller Angriffsvektor in AWS EKS. Dieser wurde von An Trinh und Duc Nguyen im Calif-Blog veröffentlicht . Bei diesem Angriffsvektor erlangt ein Angreifer in einem Pod mit niedrigen Berechtigungen die Kontrolle über den Kubernetes-Cluster.

Und so funktioniert es:

Phase 1: Temporäre Token-Anforderung

1. Ein von einem Angreifer kontrollierter Pod kann die AWS-API um ein Kubernetes-Token bitten.
2. Der STS (Security Token Service) fragt: „Wer möchte dieses Token haben“?
3. Die Antwort ist der EC2-Server selbst. Beachten Sie, dass nicht der Pod antwortet, sondern der Server, auf dem er ausgeführt wird.
4. Der STS fragt, welche Berechtigungen zur Verfügung gestellt werden sollen.
5. Die IAM wird abgefragt und ordnet den EKS EC2-Server der NodeInstanceRole AWS zu.

Es ist wichtig zu verstehen, dass AWS und Kubernetes zwei verschiedene Berechtigungssysteme sind. Aber jetzt werden sie aufeinander abgebildet.

1. Die AWS-Berechtigungen werden auf die System:Node-Berechtigungen in Kubernetes abgebildet.

Phase 2: Privilegieneskalation

1. Dann kann der Angreifer diese System:Node-Berechtigungen nutzen, um nach den Token anderer Anwendungen zu fragen, die sich neben ihm auf demselben Knoten befinden.

Phase 3: Seitliche Verschiebung

1. Sobald der Angreifer Zugriff auf weitere Token mit unterschiedlichen Berechtigungen erhält, könnten einige von ihnen privilegiert genug sein, um eine seitliche Bewegung und eine Privilegienerweiterung durchzuführen, bis er die vollständige Kontrolle über den gesamten Cluster erlangt.

Durch diesen AWS EKS-Angriffsvektor kann ein Angreifer die Berechtigung zur Kompromittierung des gesamten Clusters erlangen, indem er sich lediglich den anfänglichen Zugriff auf einen Pod mit geringen Rechten verschafft.

Schlussfolgerung

Mehr über Kubernetes zu erfahren, ist für die Absicherung Ihrer Cluster unerlässlich, denn die Leistungsfähigkeit und Komplexität von Kubernetes erfordert ein besseres Verständnis der Architektur, des Betriebs und der Schwachstellen.

Insbesondere empfehlen wir, die Feinheiten von riskanten Rollen und Konfigurationen zu verstehen, da dies die Angriffsvektoren sind, die zu einer vollständigen Kompromittierung Ihres Kubernetes-Clusters führen können. Indem sie wie ein Angreifer denken und der Sicherheitsausbildung und -schulung Priorität einräumen, können Unternehmen ihre Kubernetes-Bereitstellungen stärken und ihre Anwendungen und Daten schützen.

 

Quelle: Pentera-Blog

---

Ihr Kontakt zu uns:

Matan Katz, Regional Development

Hier direkt einen Termin buchen:

https://pentera.oramalthea.com/c/MatanKatz

Oliver Meroni, Regional Sales Manager Switzerland & Austria, Pentera

Hanspeter Karl, Area Vice President DACH, Pentera