Container- und Kubernetes-Sicherheit: Image, Steuerungsebene, Laufzeit

Container- und Kubernetes-Sicherheit ist der blinde Fleck vieler Blue Teams, deren Erkennung auf klassische Server und Endpunkte ausgerichtet ist. Container laufen anders: Sie starten in Sekunden, leben oft nur Minuten, teilen sich einen Kernel und werden von einer eigenen Steuerungsebene orchestriert, meist Kubernetes. Diese Eigenheiten machen die klassische Erkennung schwer und schaffen neue Angriffsflächen, aber sie bieten auch eine Chance: Ein Container ist viel vorhersehbarer als ein Server, und genau das lässt sich zur Erkennung nutzen. Dieser Beitrag erklärt die drei Säulen der Container-Verteidigung, die typischen Fehlkonfigurationen und die Angriffsmuster, und er baut auf dem Beitrag zur Cloud-Sicherheit auf, weil Kubernetes meist in der Cloud läuft und dieselbe Grundlogik teilt.

Säule 1: Image-Sicherheit vor dem Start

Ein Container startet aus einem Image, und das Image ist die erste Angriffsfläche. Wer ein verwundbares oder manipuliertes Image startet, hat den Angriff bereits importiert, bevor der Container überhaupt läuft. Die Maßnahmen setzen deshalb vor dem Start an. Die Images werden auf bekannte Schwachstellen gescannt, dieselbe Disziplin wie im Schwachstellenmanagement, nur auf die Bausteine des Images bezogen. Sie kommen aus vertrauenswürdigen Quellen, idealerweise signiert, damit niemand ein manipuliertes Image unterschieben kann, das ist die Container-Ausprägung des Supply-Chain-Angriffs. Und sie enthalten keine Geheimnisse: Zugangsdaten, Schlüssel und Token gehören nicht ins Image, weil jeder, der das Image hat, sie auslesen kann. Die Image-Sicherheit ist die günstigste Schicht, weil ein sauberes Image einen ganzen Angriffsweg schließt, bevor er beginnt.

Säule 2: die Steuerungsebene absichern

Kubernetes hat eine zentrale Steuerungsebene, deren Herzstück die Kubernetes-API ist. Über sie wird alles gesteuert: Container starten, Rechte vergeben, Geheimnisse verwalten, in laufende Container hineinschauen. Damit ist die API das neue Kronjuwel, das Gegenstück zum Domain Controller in der klassischen Welt, und ihre Absicherung ist die wichtigste Aufgabe. Die Grundpfeiler:

• Minimale Rechte (RBAC). Kubernetes steuert den Zugriff über rollenbasierte Rechte. Jede Identität, jeder Dienst bekommt nur die Rechte, die er wirklich braucht. Zu weit gefasste Rechte sind die häufigste Fehlkonfiguration und der häufigste Weg zur Rechteausweitung. Dasselbe Prinzip wie in der Active-Directory-Härtung.
• Die API nicht öffentlich. Eine aus dem Internet erreichbare, schwach gesicherte Kubernetes-API ist ein häufig ausgenutzter Weg. Der Zugang gehört eingeschränkt und stark authentifiziert.
• Geheimnisse richtig verwalten. Kubernetes verwaltet Geheimnisse, aber standardmäßig nur schwach geschützt. Sie gehören verschlüsselt und der Zugriff darauf eng begrenzt, denn wer die Geheimnisse hat, hat die Zugänge.
• Die Audit-Logs aktivieren. Die Kubernetes-API kann jede Aktion protokollieren, wer hat was wann getan. Das ist das Gegenstück zu den Control-Plane-Protokollen der Cloud und die Grundlage jeder Erkennung auf der Steuerungsebene. Standardmäßig sind sie oft nicht vollständig aktiviert.

Säule 3: die Laufzeit-Erkennung

Hier liegt die größte Chance der Container-Verteidigung, und sie ergibt sich aus einer Eigenheit: Ein Container ist zur Laufzeit sehr vorhersehbar. Er wurde für genau eine Aufgabe gebaut und tut fast immer dasselbe, dieselben Prozesse, dieselben Verbindungen, dieselben Dateizugriffe. Das macht die Abweichung zu einem starken Signal. Wenn ein Container, der nur einen Webdienst ausführen soll, plötzlich eine Shell startet, eine ungewöhnliche ausgehende Verbindung aufbaut, ein Systemwerkzeug ausführt oder versucht, aus dem Container auszubrechen, dann ist das fast sicher bösartig, weil es nicht zum vorgesehenen Verhalten passt. Diese Laufzeit-Erkennung, oft über Werkzeuge, die das Verhalten der Container auf Kernel-Ebene beobachten, ist die Container-Variante der verhaltensbasierten Erkennung. Die typischen Angriffsmuster, auf die man achtet:

• Shell in einem Container. Ein interaktiver Zugriff auf einen laufenden Container, der im Normalbetrieb nicht vorkommt, ist ein starkes Signal für einen Angreifer, der sich eingenistet hat.
• Container-Ausbruch. Der Versuch, aus dem Container auf den darunterliegenden Host auszubrechen, oft über einen zu privilegierten Container oder eine Kernel-Schwachstelle. Ein privilegierter Container ist die häufigste Voraussetzung dafür und gehört vermieden.
• Kryptomining. Der häufigste Zweck eines übernommenen Containers: ungewöhnliche Rechenlast und Verbindungen zu Mining-Netzen.
• Verbindung zur Kubernetes-API von innen. Ein Container, der plötzlich versucht, die API anzusprechen, will sich oft Rechte verschaffen oder das Cluster erkunden.

Die typischen Fehlkonfigurationen

Wie in der Cloud sind die meisten Vorfälle keine ausgefeilten Angriffe, sondern die Ausnutzung von Fehlkonfigurationen. Die häufigsten: privilegierte Container, die viel mehr dürfen als nötig und den Ausbruch erleichtern; zu weit gefasste RBAC-Rechte, die eine Rechteausweitung ermöglichen; eine öffentlich erreichbare oder schwach geschützte Kubernetes-API; Geheimnisse im Image oder im Klartext; fehlende Netzwerkregeln zwischen den Containern, sodass ein übernommener Container das ganze Cluster erreicht, dieselbe Lücke wie ein flaches Netz aus dem Beitrag zur Netzwerksegmentierung. Diese Fehler zu finden, bevor der Angreifer sie findet, ist die Aufgabe der Konfigurationsprüfung, die die Cluster-Konfiguration laufend gegen bewährte Sicherheitsvorgaben prüft.

Womit ein Blue Team anfängt

1. Die Audit-Logs der API aktivieren und ins SIEM bringen. Ohne die Protokolle der Steuerungsebene ist keine Erkennung möglich. Das ist der erste Schritt.
2. Images scannen. Jedes Image vor dem Einsatz auf Schwachstellen prüfen und aus vertrauenswürdigen Quellen beziehen.
3. RBAC aufräumen. Die zu weit gefassten Rechte finden und einengen, besonders die, die den Zugriff auf die ganze Steuerungsebene erlauben.
4. Privilegierte Container abschaffen. Die Container mit zu vielen Rechten finden und entschärfen, weil sie die Voraussetzung für den Ausbruch sind.
5. Laufzeit-Erkennung einführen. Ein Werkzeug, das das Verhalten der Container beobachtet und auf die genannten Muster alarmiert, als Kern der laufenden Überwachung.

Fazit

Container- und Kubernetes-Sicherheit ist kein völlig neues Feld, sondern die Übertragung vertrauter Prinzipien auf eine schnelle, kurzlebige Umgebung mit eigener Steuerungsebene. Die drei Säulen greifen ineinander: die Image-Sicherheit schließt den Angriff vor dem Start, die Absicherung der Steuerungsebene schützt das neue Kronjuwel, und die Laufzeit-Erkennung nutzt die Vorhersehbarkeit der Container, um jede Abweichung sichtbar zu machen. Der rote Faden ist derselbe wie in der Cloud: minimale Rechte, die Steuerungsebene protokollieren und überwachen, und die Konfiguration laufend prüfen. Für ein Blue Team, das aus der klassischen IT in die Container-Welt hineinwächst, ist die wichtigste Einsicht, dass ein Container zwar flüchtig, aber vorhersehbar ist, und dass genau diese Vorhersehbarkeit die beste Grundlage der Erkennung ist.