Maßnahmen für mehr Sicherheit in Container-Umgebungen Kubernetes-Cluster und Container absichern

Kubernetes Cluster sind bei vielen Unternehmen im Einsatz. Sie müssen jedoch abgesichert werden, denn auch sie sind vor klassischen IT-Sicherheitsrisiken nicht gefeit. Dies erfordert eine Reihe von bewährten Verfahren und ein kompetentes Sicherheitsteam.

Als Open-Source-Projekt wird Kubernetes ständig aktualisiert. Sein GitHub-Repository ist eines der aktivsten Repositories der Plattform. Als solches werden ständig neue Funktionen, Verfeinerungen und Sicherheitsupdates eingeführt.

Alle vier Monate wird eine neue Hauptversion von Kubernetes veröffentlicht. Jede neue Version enthält neue Funktionen zur Verbesserung des Dienstes, aber das kann auch neue Sicherheitsprobleme oder Bugs mit sich bringen – etwas, wofür jede Software anfällig ist, insbesondere wenn sie häufig aktualisiert wird.

Sicherheitslücken finden sich jedoch auch in älteren Versionen. Es ist daher wichtig zu verstehen, wie das zuständige IT-Team mit Sicherheitsupdates in älteren Versionen umgeht. Im Gegensatz zu Linux-Distributionen oder anderen Plattformen verfügt Kubernetes über keine LTS-Version (Long Term Support).

Das System versucht daher, Sicherheitsaktualisierungen auf die drei zuletzt veröffentlichten Hauptversionen zurück zu portieren. Es ist daher von entscheidender Bedeutung, dass ein Cluster in einer der drei neuesten Hauptversionen gehalten wird, das stets über die neuesten Sicherheitspatches verfügt. Nach Adam Riese sollten also mindestens alle zwölf Monate Aktualisierungen auf die neueste Hauptversion geplant werden.

Neben den Hauptkomponenten verwaltet Kubernetes auch die Nodes, auf denen der dem Cluster zugewiesene Workload ausgeführt wird. Bei diesen Nodes kann es sich um physische oder virtuelle Maschinen handeln, auf denen ein Betriebssystem läuft. Jeder Node ist somit ein potenzieller Angriffsvektor, der zur Behebung von Sicherheitsproblemen aktualisiert werden muss. Die Nodes müssen daher so gut aufgeräumt wie möglich sein, um die Angriffsfläche zu reduzieren.

Nutzer-Zugriffe limitieren

Die rollenbasierte Zugriffskontrolle (RBAC) ist eine der besten Möglichkeiten, um zu kontrollieren, wer und wie Zugriff auf den Cluster hat. Sie ermöglicht einen granularen Berechtigungsansatz, um die Berechtigung jedes Benutzers zu definieren. Die Regeln sind immer additiv, so dass jede Berechtigung explizit festgelegt werden muss.

Mit RBAC ist es möglich, die Zugriffsberechtigungen (Anzeigen, Lesen oder Schreiben) auf jedes Kubernetes-Objekt einzuschränken; dies reicht von den Pods (der kleinsten Kubernetes-Computereinheit) bis hin zu den Namespaces, also virtuellen (Unter-)Clusterm.

RBAC lässt sich auch über OpenID-Connect-Token an einen anderen Verzeichnisdienst anschließen. Auf diese Weise können Benutzer- und Gruppenverwaltung zentralisiert definiert und innerhalb der Organisation weiterverbreitet werden.

Die Zugriffsberechtigung ist nicht nur auf Kubernetes beschränkt. Manchmal müssen Benutzer auf einen Cluster-Nodes zugreifen, um z.B. Probleme zu identifizieren. In solchen Fällen ist es besser, zur Lösung dieser Probleme temporäre Benutzer anzulegen und diese dann zu löschen.

Best Practises zur Absicherung von Containern

Docker, die bekannteste Containertechnologie, besteht aus mehreren Schichten. Die innerste Schicht ist die primitivste Struktur, während die äußere Schicht die spezifischste ist. Daher beginnen alle Docker-Images mit irgendeiner Art von Distribution oder Sprachunterstützung, wobei jede neue Schicht die vorherige Funktionalität bis zur allerletzten Schicht hinzufügt oder modifiziert. Der Container sollte dann alles enthalten, was er zum Hochfahren der Anwendung benötigt.

Diese Schichten (auch Images genannt) können öffentlich (im Docker Hub) oder in einer anderen (privaten) Image Registry vorgehalten werden. Das Image wird dabei in zwei Formen ausgedrückt: als Name plus Label (z.B. node:latest) oder mit seinem unveränderlichen SHA-Hashwert (z.B. sha256:d64072a554283e64e1bfeb1bb457b7b293b6cd5bb61504afaa3bdd5da2a7bc4b für das gleiche Docker-Image).

Das mit dem Label verknüpfte Image kann jederzeit vom Repository-Besitzer geändert werden. Das letzte Tag zeigt die letzte verfügbare Version an. Es bedeutet auch, dass sich beim Erstellen eines neuen Images oder beim Ausführen eines solchen mit einem Tag die innere Schicht plötzlich und ohne Vorankündigung ändern kann.

Dieses Vorgehen wirft zwei Probleme auf:

• Man verliert die Kontrolle darüber, was in einer Kubernetes-Instanz läuft, da eine höhere Schicht aktualisiert werden und einen Konflikt erzeugen kann, oder ...

• das Image kann absichtlich geändert werden, um eine Sicherheitslücke zu erzeugen.

Um das erste Problem zu verhindern, sollte die Verwendung des neuesten Tags vermieden und ein Tag wie Node:14.5.0 verwendet werden. Und um dieses zweite Problem zu vermeiden, entscheidet man sich für ein offizielles Image, klont es in der privaten Repository oder verwendet den SHA-Wert.

Ein anderer Ansatz ist die Verwendung eines Tools zur Erkennung von Schwachstellen, um die verwendeten Images kontinuierlich zu scannen. Diese Werkzeuge können zusammen mit Continuous Integration-/Continuous Deployment (CI/CD)-Pipelines laufen und das Image-Archiv überwachen, um bisher unentdeckte Probleme zu identifizieren.

Beim Erstellen eines neuen Images ist es außerdem wichtig, daran zu denken, dass jedes Image nur einen Dienst enthalten sollte. Das gesamte Image sollte so erstellt werden, dass es nur die für diese Anwendung erforderlichen Abhängigkeiten aufweist und sonst nichts. Dadurch wird die Angriffsfläche auf nur die für den Dienst wesentlichen Komponenten reduziert. Wenn nur eine Anwendung pro Image vorhanden ist, erleichtert dies auch die Aktualisierung auf eine neue Version und die Zuweisung von Ressourcen im Orchestrator.

Netzwerksicherheit mit Service Mesh

Kubernetes enthält virtuelle Netzwerke innerhalb des Clusters, die den Zugriff zwischen den Pods einschränken und den externen Zugriff erlauben können, so dass nur auf erlaubte Dienste zugegriffen werden kann. Es ist eine primitive Lösung, die in kleinen Clustern gut funktioniert.

Größere Cluster, die mehrere Dienste enthalten, die von verschiedenen Teams entwickelt wurden, sind jedoch weitaus komplexer, und ein zentralisierter Ansatz ist möglicherweise unmöglich zu verwalten. In solchen Fällen ist ein Service Mesh derzeit die beste verfügbare Methode. Es schafft eine Netzwerkverschlüsselungsschicht, die es den Diensten ermöglicht, sicher miteinander zu kommunizieren. Sie arbeiten in der Regel als Sidecar-Agent, der an jedem Pod befestigt ist und die Kommunikation zwischen den Diensten ermöglicht.

Bei Service Mesh geht es nicht nur um Sicherheit; sie ermöglichen auch die Erkennung, Überwachung/Verfolgung/Protokollierung von Diensten und vermeiden Dienstunterbrechungen, z. B. durch Anwendung eines Unterbrechungsmusters. Da die Anwendungen ständig aktualisiert werden, reicht die Implementierung der oben genannten Mittel zur Sicherung eines Clusters allein nicht aus, da immer noch das Risiko eines Sicherheitsvorfalls besteht.

Die Verwendung von Ressourcenquoten, bei denen Kubernetes die Ausfalldeckung auf die festgelegten Einschränkungen beschränkt, ist ein weiterer wichtiger Schritt. Wenn die Einschränkungen gut konzipiert sind, werden sie verhindern, dass alle Clusterdienste aufgrund von Ressourcenerschöpfung nicht verfügbar sind.

Monitoring und Logging

Die Überwachung des Clusters, vom Cluster bis hin zu den Pods, ist wesentlich, um Ausfälle aufzudecken und ihre Ursache zu ermitteln. Es geht darum, anomales Verhalten aufzudecken. Wenn der Netzwerkverkehr zugenommen hat oder sich die CPU der Nodes anders verhält, erfordert dies weitere Untersuchungen zur Problemfindung.

Während es bei der Überwachung eher um Metriken wie CPU, Speicher und Netzwerk geht, kann die Protokollierung zusätzliche (historische) Informationen liefern, die helfen können, ungewöhnliche Muster zu erkennen oder die Ursache des Problems schnell zu identifizieren.

Prometheus und Graphana zusammen sind wirksame Werkzeuge für die Überwachung von Kubernetes. Prometheus ist eine hochleistungsfähige Zeitreihendatenbank, während Graphana ein grafisches Dashboard ist, das Prometheus-Daten lesen kann und leicht einsehbare Dashboards bietet. ElasticSearch ist ein weiteres nützliches Tool und auch eines der beliebtesten für die Bereitstellung einer nahezu in Echtzeit erfolgenden zentralen Protokollierung der Anwendung, der Nodes und des Kubernetes selbst.

Cloud vs. On-Premises

Eine Kubernetes-Installation kann entweder vor Ort erfolgen oder einen Cloud-Management-Dienst nutzen. Im Vor-Ort-Szenario muss jede Konfiguration – das Hochfahren neuer Rechner, das Einrichten des Netzwerks und die Sicherung der Anwendung – manuell bereitgestellt werden. Cloud Managed Services wie Google GKE, AWS EKS oder Azure AKS ermöglichen die Installation von Kubernetes mit minimaler Konfiguration und sind mit anderen Services des Cloud-Providers kompatibel.

Aus Sicherheitssicht erfordern On-Premises-Lösungen viel mehr Aufmerksamkeit. Jedes neue Update muss vom System heruntergeladen und konfiguriert werden, und auch die Nodes müssen aktualisiert werden. Es wird daher empfohlen, nur mit einem erfahrenen Team vor Ort Kubernetes einzurichten.

Bei Cloud-Management-Diensten hingegen ist der Prozess wesentlich einfacher, da Kubernetes bereits installiert ist und der Cloud-Anbieter alle Nodes mit den neuesten Sicherheitsfunktionen auf dem neuesten Stand hält. Aus der Cluster-Perspektive ermöglichen die meisten Cloud-Anbieter dem Benutzer die Auswahl der Kubernetes-Version aus einem Satz und bieten auch Möglichkeiten zur Aktualisierung auf eine neue Version. So ist es zwar einfacher, aber auch weniger flexibel.

Fazit

Angesichts ständiger Aktualisierungen und der Flut neuer Werkzeuge auf dem Markt kann es eine Herausforderung sein, auf dem neuesten Stand zu bleiben und die Schwachstellen zu beherrschen. Sicherheitsverstöße sind unvermeidlich. Bei Kubernetes ist die Herausforderung noch größer, da es mehr als nur ein Werkzeug ist.

Vielmehr handelt es sich bei Kubernetes um eine Reihe von Werkzeugen, die andere Werkzeuge, Maschinen und Netzwerke verwalten, und die Absicherung ist daher von wesentlicher Bedeutung. Aber bei so vielen beweglichen Teilen ist es keine triviale Aufgabe, ein Kubernetes sicher zu halten, deshalb empfehlen sich die folgenden Richtlinien:

• Scannen Sie Anwendungen, die auf Kubernetes laufen, auf Sicherheitsprobleme.

• Beschränken und kontrollieren Sie den Zugriff.

• Stellen Sie sicher, dass alles mit den neuesten Sicherheitsupdates gepatcht ist, und überwachen Sie den Cluster kontinuierlich, um Ausfälle sofort zu beheben und den Schaden zu mindern.

Die Herausforderung ist noch größer bei On-Premises-Implementationen, bei denen es echte Hardware zu verwalten, Automatisierungen zu erstellen und mehr Software zu aktualisieren gibt. Die Befolgung der hier besprochenen Punkte kann der IT-Abteilung einen großen Sicherheitsvorteil verschaffen und dazu beitragen, ihre Kubernetes-Umgebung sicher und betriebsbereit zu halten.

* Jan Tietze ist Director Security Strategy EMEA bei SentinelOne.

(ID:46803628)