pattilabelle - Fotolia
Container: Sicherheit in Kubernetes-Umgebungen herstellen
Die Kombination Container und Kubernetes gehört mittlerweile zum Standard, um bestimmte Szenarien abzubilden. Umso wichtiger wird es, dieses Zusammenspiel besser abzusichern.
Softwareentwickler taten sich lange schwer, eine Software von einer Umgebung auf eine andere zu übertragen. Notwendige Anpassungen betrafen nicht nur die Performance, sondern oft genug auch die Funktionen. Container brachten die Lösung, indem sie alle Komponenten in einem Paket bündeln. Unterschiede im Betriebssystem und der zugrunde liegenden Infrastruktur stellen heute kein Hindernis mehr dar. Die Container-Laufzeit abstrahiert sie weg. Die Verwendung von Containern und ihr Betrieb in Clustern optimiert so den Prozess der Softwareentwicklung.
Mittlerweile hat es sich für DevOps-Teams zum Standard entwickelt, Container – meist Docker – über einen Orchestrator wie Kubernetes zu betreiben. Diese Konstellation erleichtert es zudem, viele Apps in einer heterogenen Umgebung kombiniert zu nutzen und zu verwalten. Dieses Zusammenspiel von Orchestrator und Containern eignet sich daneben für das Computing von Cloud-nativen Apps.
Security-Grundlagen für Container
Container- und Kubernetes-Umgebungen müssen sicher laufen und vor potenziellen Cyberattacken geschützt sein. Das Betrachten, wo mögliche Angriffspunkte bestehen, beginnt mit dem Erstellen eines Containers über das Container-Image. Dieses definiert den ausführbaren Code, unterstützende Bibliotheken, Rechenanforderungen und andere Objekte für etwaige Prozesse. Ein anfälliges Image ist eine potenzielle Schwachstelle, sodass ein Container durch Cyberkriminelle infiziert oder ausgenutzt werden kann. Dadurch würde auch der Host, auf dem der Container läuft, in Gefahr geraten.
Container-Images sollten daher gescannt werden. Stimmen Sicherheits- und Qualitätsanforderungen, signiert und authentifiziert man die Images, womit angezeigt wird: Sie stammen aus einer vertrauenswürdigen Quelle (Registry). Weitere grundlegende Sicherheitsvorkehrungen betreffen die Computer-Laufzeit, um Container und Host zu schützen. Dazu wird der Zugriff auf die Computer-Laufzeit für die Anwendungen eingeschränkt. Außerdem sollte die Netzwerkkommunikation verschlüsselt ablaufen.
Der Blick auf die Anwendungen
In den Containern laufen Anwendungen, die angreifbar werden, wenn ihre Sicherheits-Patches nicht oder nicht ausreichend implementiert werden. Zu bedenken ist folgender Umstand: Eine Bibliothek, die eine Anwendung nutzt, lässt sich aus verschiedenen Basis-Images installieren, die alle aktualisiert werden müssen. Gefragt ist daher eine Lösung, die alle genutzten Container-Images darauf prüft, ob sie aus vertrauenswürden Quellen stammen, und dann den Patch aufspielt. Dadurch wird verhindert, dass Cyberkriminelle ein Image beispielsweise zum Krypto-Mining missbrauchen. Diesem Angriffsszenario beugt ein Nutzer bei Docker mit „Content Trust“ vor. Das Tool stellt Images in einem Cluster oder „Swarm“ zuverlässig bereit und kontrolliert, ob es sich tatsächlich um die vom Anwender gewünschten Images handelt. Dennoch empfiehlt es sich, über Container-spezifische, automatisierte Scanning-Technologien nachzudenken. Ihre Image-Prüfung senkt die Gefahr weiter, auf der Anwendungsebene Angriffspunkte zu bieten.
Hoheit über die Steuerungsebene
Auch für die Kubernetes-Installation, über die eine Firma ihre Container orchestrieren will, gibt es einige sicherheitsrelevante Aspekte. Zunächst einmal geht das größte Risiko von externen Angriffen und Fehlkonfigurationen aus. Am lukrativsten ist für Angreifer der Zugriff auf die REST-API. Dann steht ihnen das gesamte Cluster offen. Sie können zum Beispiel bösartige Container installieren, um Informationen aus Datenbanken zu ziehen oder um Ressourcen für Krypto-Mining abzuzweigen. Die zu schützende REST-API nennt sich kube-api-server und bildet das Frontend für die Steuerungsebene. Über diese, die Control Plane, läuft die gesamte Kommunikation. Nutzer definieren und kontrollieren alle Kubernetes-Managementfunktionen über die REST-API.
„Eine Anwendung kann es erforderlich machen, hunderte von Containern zu sichern, die über mehrere virtuelle Maschinen hinweg in verschiedenen Cloud-Service-Plattformen verteilt sind.“
Richard Werner, Trend Micro
Sicherheit auf der Steuerungsebene verlangt integre, kritische Kubernetes-Daten und Verzeichnisse, die sich genau daraufhin überwachen lassen. Bei Aktivierung meldet das entsprechende Kubernetes-Tool jede geänderte Einstellung. Das Beschränken der Kommunikation über die API stellt einen weiteren wichtigen Schritt dar, der sich mit einer Firewall durchsetzen lässt. Diese lässt nur den Datenaustausch von Maschinen im Cluster mit der Control Plane zu, die administrative Aufgaben erfüllen. Noch mehr Sicherheit verspricht, den Verkehr zu und von der API zu überwachen, was ein Intrusion Prevention System (IPS) mit SSL-Entschlüsselungsfähigkeiten (Secure Sockets Layer) übernehmen kann.
Keine öffentlich zugänglichen Instanzen
Das Überwachen des API-Verkehrs ist das eine, dass der API-Server öffentlich nicht zugänglich ist, das entscheidende andere. Dieser kritische Fehler passiert leider zu oft, warnen Sicherheitsforscher, die immer wieder über die IoT-Suchmaschine Shodan tausende fehlkonfigurierte Instanzen finden. Auf solche offenen Hosts stoßen auch Cyberkriminelle und Bots früher oder später. Dem beugen Regeln für die Firewall vor, die den API-Verkehr im Cluster auf das interne Netzwerk und VPN beschränken. Jeglicher Service, der von Kubernetes genutzt wird, gehört hinter eine Firewall. Zudem ist sicherzustellen, dass die Netzwerk-Policy den ankommenden Verkehr standardmäßig nicht zulässt.
Der offene Zugang betrifft in ähnlicher Dimension auch den Hauptspeicherort etcd. Dort liegen die Daten für alle Clusterobjekte, auf die Cyberkriminelle allzu gern zugreifen würden. Denn sie könnten dann tun, wonach ihnen ist – Pods aufsetzen, in denen die Container laufen, Pods löschen, Anmeldeinformationen einsehen und vieles mehr. Das verhindert eine Verschlüsselung, die sowohl während der Übertragung als auch im Ruhezustand (At-Rest) aktiviert ist. Den internen, unberechtigten Zugriff unterbindet man mit Role Based Access Control (RBAC), um festzulegen, auf was Nutzergruppen und Servicekonten im Cluster zugreifen dürfen.
Angriffspunkte auf allen Ebenen eliminieren
Eine Anwendung kann es erforderlich machen, hunderte von Containern zu sichern, die über mehrere virtuelle Maschinen hinweg in verschiedenen Cloud-Service-Plattformen verteilt sind. An der Stelle versagen gängige Sicherheitskonzepte. Die in ihnen steckenden Grundsätze, um Angriffspunkte via Firewall, Verschlüsselung und Verkehrsbeschränkungen zu vermeiden, lassen sich gleichwohl auf eine Container-Kubernetes-Umgebung übertragen – und konsequent anwenden. Es ist möglich und angesichts der Bedrohungslage auch nötig, eine Architektur zu betreiben, die durchgehend alle potenziellen Angriffspunkte gegenüber einer Umgebung eliminiert, die Ebenen übergreifend auf Standardkonfigurationen setzt.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
