Wie sich Container sicher mit Kubernetes orchestrieren lassen
Autor/Redakteur: Richard Werner, Business Consultant bei Trend Micro/gg
Kubernetes ist das in Cloud-Umgebungen am meist eingesetzte Container-Orchestration-System. Diese Verbreitung macht es für Cyberkriminelle attraktiv, weshalb Cloud-Administratoren eine Sicherheitsstrategie benötigen, die vom Master-Knoten bis zum Container-Image reicht. Ein Überblick zu den relevanten Sicherheitsmaßnahmen.
Container, meist Docker, und Container-Orchestratoren wie Kubernetes erleichtern nicht nur den Betrieb einer Vielfalt von Anwendungen in einer heterogenen Umgebung, sondern auch die kombinierte Nutzung von Apps in vielen Variationen. Betreibt ein Unternehmen seine Cluster als Managed Services wie etwa Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (Amazon EKS) oder Google Kubernetes Engine (GKE), so muss der Cloud-Anbieter die Kontrolle über die Sicherheit übernehmen. Dennoch ist ein besseres Verständnis der verfügbaren Sicherheitsoptionen hilfreich, um sicherzustellen, dass der Cloud-Anbieter die empfohlenen Best Practices befolgt. Richtet sich eine Organisation ihre eigenen Control Planes ein, ist tieferes Wissen noch wichtiger. Cloud-Administratoren müssen vor allem die drei Bedrohungsszenarien externe Angriffe, Fehlkonfigurationen und angreifbare Anwendungen im Blick behalten.
Das Gehirn vor externen Angriffen schützen
Wenden wir uns zunächst dem Gehirn zu – dem Kubernetes Control Plane. Es fungiert als Hauptknoten im Cluster und verwaltet die Worker Nodes. Die gesamte Kommunikation läuft über kube-api-server, der letztendlich ein REST API ist, das alle Management- und Betriebsfunktionen definiert und kontrolliert. Verschaffen sich Cyberkriminelle Zugang zur REST API, können sie den gesamten Cluster kompromittieren, indem sie die Pods (in denen die Container platziert sind) manipulieren, neue aufsetzen, bereits laufende bearbeiten oder sogar ganz entfernen.
Eine der grundlegenden Maßnahmen zur Sicherung des Control Plane ist die Integritätsüberwachung der kritischen Kubernetes-Dateien. Auf diese Weise kommt sofort über jede Änderung der Konfiguration eine Benachrichtigung. Eine Liste der wichtigsten Dateien und Verzeichnisse, die das Team ständig überwachen muss, zusammen mit den empfohlenen Ownership- und Berechtigungsebenen, sind in der neuesten CIS Kubernetes Benchmark v1.5.1 detailliert aufgeführt.
Entscheidend ist, dass diese API lediglich von den Maschinen in einem Cluster zu erreichen ist, die Administrationsaufgaben erfüllen müssen. Es empfiehlt sich daher eine Firewall-Regel, die durchsetzt, dass nur die Maschinen auf die API zugreifen können, die das auch tun müssen.
API-Server abschotten
Viele Angreifer und Bots suchen im Internet ständig nach offen zugänglichen Kubernetes-API-Servern, was leider häufig Aussichten auf Erfolg hat. Denn viele Firmen lassen ihre API-Server öffentlich zugänglich – ein kritischer Fehler.
Die Entwickler sollten das Cluster API nur über das interne Netzwerk (oder Unternehmens-VPN) erreichen können. Dies lässt sich leicht bewerkstelligen, indem die entsprechenden Regeln für die Firewall oder Sicherheitsgruppen (im Fall von AWS) festgelegt werden. Hier gilt es an die Notfallsituation zu denken, in welcher der Cluster-Administrator keinen sofortigen Zugriff auf den Firmen-Laptop oder ein VPN hat. In dem Fall sollte der Zugriff auf den Cluster durch eine sichere Auflistung der IP des Cluster-Administrators gewährleistet werden, vorzugsweise auf den spezifischen API-Port. Daneben ist es ratsam, ein Intrusion Prevention System (IPS) mit Secure Sockets Layer (SSL)-Entschlüsselungsfähigkeiten wie Trend Micro TippingPoint Threat Protection System einzusetzen, um den Verkehr zu und von der API zu überwachen.
Fehlkonfigurationen vermeiden und Berechtigungen zuweisen
Wie wichtig der Konfigurationsaspekt bei Kubernetes ist, haben Sicherheitsforscher mit dem Scan der IoT-Suchmaschine Shodan gezeigt. Weltweit gibt es nahezu 3.000 Hosts, bei denen “etcd” öffentlich zugänglich ist. “etcd” ist der Hauptspeicherort für Daten im Cluster. Alle Clusterobjekte werden hier vorgehalten. Gelingt es einem Angreifer auf irgendeine Weise, den API-Server zu umgehen und Objekte direkt in “etcd” zu manipulieren, so wäre es, als hätte er vollen Zugriff auf den gesamten Cluster. Er könnte Pods erstellen, Geheimnisse lesen und sensible Daten wie Anmeldeinformationen einsehen. Um dies zu verhindern, müsste nicht nur die Verschlüsselung während der Übertragung aktiviert sein, sondern auch die Verschlüsselung im Ruhezustand (At-Rest).
Schon bei der Authentifizierungskonfiguration können viele Fehler passieren, weil sie sehr komplex ist. So gibt es mehrere Arten der Authentifizierung (rollen-, attribut- oder knotenbasiert). Als Hilfe können Cloud-Administratoren den Befehl “kubectl auth can-i” verwenden, um bestimmte Berechtigungen abzufragen. Kubernetes Benutzer- und Service-Konten sollten lediglich die Berechtigungen erhalten, die sie tatsächlich benötigen. Mit Roll Based Access Control (RBAC) lässt sich festlegen, wer worauf in dem Cluster zugreifen kann.
