Antworten auf die wichtigsten Kubernetes Sicherheitsfragen
Mit zunehmender Beliebtheit der Containernutzung setzen immer mehr Organisationen auf Kubernetes. Sie suchen nach Möglichkeiten, um Container zu verwalten und neue Anwendungen effizienter und schneller zu erstellen und zu veröffentlichen.
Kubernetes bringt neue Anwendungen mit allem zusammen, was für eine einheitliche Ausführung in jeder beliebigen Umgebung nötig ist. Kubernetes wurde ursprünglich von Google entwickelt und wird jetzt von derCloud Native Computing Foundation weitergeführt. Es dient der bedarfsorientierten Automatisierung von Rollouts und Verwaltung containerisierter Anwendungen und hilft gleichzeitig, etliche Probleme und Hürden in Zusammenhang mit einer schnellen, automatisierten Softwarebereitstellung zu beseitigen.
Gleichzeitig werden Container und Container-Verwaltungstools wie Kubernetes aber auch ein immer beliebteres Ziel für Hackerangriffe. Gerade weil Kubernetes bei Unternehmen immer populärer wird, sollte man sich unbedingt auch mit den damit verbundenen Sicherheitsproblemen vertraut machen. Nachfolgend einige Sicherheitsfragen, die wir im Zusammenhang mit Kubernetes besonders oft hören.
Können Container als Root laufen?
Wenn ein Container als Root eingesetzt wird, können Hacker nach Umgehung aller Verteidigungsmechanismen den uneingeschränkten Zugriff auf Ihr Netzwerk erlangen. Sobald der Container erst einmal kompromittiert wurde, kann der Angreifer das Netzwerk beliebig scannen, das Dateisystem erkunden, Pakete herunterladen und Befehle ausführen, die eigentlichen den Root-Nutzern vorbehalten sind. Bei einem solchen „Container-Szenario“ kann sich der Container nach Umgehung der Isolationsmechanismen und Erlangung weiterer Rechte auf dem Host unter der Kontrolle des Hackers sogar als Root ausgeben.
Ein solches Risiko lässt sich vermeiden, indem man Abwehrmechanismen einrichtet, durch die Container gehindert werden, sich in einem Cluster als Root auszugeben:
PodSecurityPolicy ist eine Ressource auf Cluster-Ebene. Sie kann Containern und Pods eine Anfrage zur Ausführung als Root auf dem Layer für die API-Zugriffskontrolle explizit verwehren.
Open Policy Agent ist ein Richtlinienkontrolltool, das Einschränkungen mit einer noch größeren Flexibilität durchsetzen kann.
Lassen sich sensible Volumes und Verzeichnisse auf Containern mounten?
Transparenz ist bei den Volumes und Verzeichnissen, die über die Konfiguration „hostPath“ auf Ihren Containern gemountet werden, besonders wichtig. Seien Sie sich der diversen Implikationen bewusst, wenn Sie Container auf Kubernetes Clustern mounten. Man kann bestimmte Volumes und Verzeichnisse auch auf der Host-Maschine selbst mounten. Während aber das Mounten von Containern für alltägliche Aufgaben wie Logging kein Problem darstellt, können sich aus dem Gewähren von Zugriffsrechten auf sensible Daten durchaus Sicherheitsprobleme ergeben.
Sind Dateisysteme auf read oder auf read/write eingestellt?
read ist die bevorzugte Standardeinstellung. Wenn das Root-Dateisystem oder gefährliche Dateien im read/write-Format gemountet werden, können Angreifer die Container-Escape-Schwachstelle ausnutzen, die auch als CVE-2016-9962 bekannt ist. Im Falle einer vollständigen Container Escape, kann der Angreifer den Container aus der beschränkten Umgebung herauslösen und den zugrunde liegenden Host-Server missbrauchen.
Können Pods im privileged-Modus laufen?
Wenn ein Container im privileged-Modus läuft, erhält er die meisten Systemrechte wie auf dem zugrunde liegenden Host, was die Angriffsfläche des Containers erheblich vergrößert. Erwägen Sie eine grundsätzliche Sperrung des privileged-Modus. Wenn weitere Systemaufrufe erforderlich sind, können Sie diese explizit im SecurityContext der PodSpec definieren.
Welche Richtlinien gibt es und für wen sind sie gedacht?
Nehmen Sie sich die Zeit, Ihre Regeln zu überprüfen und sicherzustellen, dass sie erwartungsgemäß funktionieren. DevOps-Tools können Sicherheitsteams eine genauere Richtlinienkontrolle über die Workloads verschaffen, die innerhalb eines Clusters ausgeführt werden. Drittanbietertools bergen zugleich aber auch ein Risiko, dass bestehende Richtlinien falsch konfiguriert oder durch andere Richtlinien überschrieben werden. Daher ist es besonders wichtig, in regelmäßigen Abständen manuelle Richtlinienprüfungen durchzuführen.
Wie läuft die Authentifizierung ab?
Kubernetes unterstützt mehrere Authentifizierungsmechanismen. Für den Zugriff auf einen Cluster werden bewährte Authentifizierungsverfahren benötigt. Auch wenn es keine allgemeingültige Lösung gibt, sollten Sie auf eine zuverlässige Authentifizierungsrichtlinie achten – mit Multi-Faktor-Authentifizierung (MFA), der Möglichkeit, Anmeldedaten zu sperren und einem absoluten Verbot der Weitergabe von Anmeldeinformationen.
Wie geht Kubernetes mit Rechten um?
Rollenbasierte Zugriffskontrollen (RBAC) bilden die Grundlage des Kubernetes Ressourcenschutzes. Das „Principle of Least Privilege“ (PoLP) schreibt vor, dass jedes Modul (also jeder Nutzer, jeder Prozess, jedes Gerät oder jedes Programm) nur die nötigen Rechte erhält, um die jeweilige Funktion auszuführen – nicht mehr, und nicht weniger. Dabei handelt es sich um Build-Rechte, mit denen das PoLP die Auswirkungen jedes Angriffs von vornherein eingrenzen kann. Entdecken Sie Tools wie rakkess, rback, krane und kubectl-who-can, die Sicherheitsteams beim richtigen Prüfen und Sperren von RBAC unterstützen.
Wie werden Kubernetes Secrets gespeichert, abgerufen, weitergegeben und widerrufen?
Secrets müssen im Interesse Ihrer Umgebung mit extremer Vorsicht behandelt werden. Sie können Secrets über die Kubernetes Secrets API und etcd oder auf ähnliche Weise speichern.
Woher kommen die Container-Images?
Ein Container Image ist ein binärer Datensatz, der eine Anwendung einschließt, zusammen mit allen zugrundeliegenden Dateien und Software-Abhängigkeiten. Container Images sind dynamisch und kommen aus Quellen wieDocker Hub oder öffentlich zugänglichen Registries, in denen eventuell auch schädliche Images vorhanden sind. Achten Sie beim Konfigurieren von Clustern darauf, dass die Image Registry vertrauenswürdig, sicher und auf Integrität geprüft ist. Nutzen Sie Image-Scantechnologien und erstellen Sie minimale Basis-Images, um die Angriffsfläche des Containers gering zu halten.
Wie wird die Netzwerksicherheit durchgesetzt?
Über Netzwerksicherheitsrichtlinien lässt sich die Kommunikation zwischen Pods einschränken. Die Netzwerkkommunikation innerhalb des Clusters sowie Egress und Ingress sollten so granular wie möglich sein. Durch eine eingeschränkte Verbindung zur Quelle bleiben Pods weiterhin gut geschützt. Nutzen Sie gegebenenfalls dieKubernetes Network Policies oder ein Service Mesh (z. B. Istio), um Ihre Netzwerkkommunikation zu überprüfen.
Sind Ihre Hosts mit Ihrem bestehenden Monitoring abgesichert?
Kubernetes verlässt sich bei der Ausführung ihrer Workloads gewöhnlich auf virtuelle Maschinen oder physische Hardware. Diese Hostmaschinen müssen angemessen abgesichert sein. Schließen Sie alle nicht benötigten Ports, patchen Sie Systeme, und sichern Sie Ihr Netzwerk angemessen ab. Folgen Sie gegebenenfalls den geltenden CIS Benchmarks für die Absicherung von Systemen.
Was ist ein Kubernetes Audit?
Kubernetes Auditing bietet sicherheitsrelevante Logs für Ereignisse und Aktivitäten, die in Ihrem Cluster auftreten können. Die Logs sollten an ein separates Log-Aggregationssystem gesendet werden, um dort von Sicherheitsteams gespeichert und analysiert zu werden.
Wie funktionieren Ingress- und Loadbalancing?
Welche externen IPs sind verfügbar? Ingress, das API-Objekt, das den externen Zugriff auf Ihren Cluster verwaltet, kann hilfreich für das Loadbalancing Ihres Traffics sein. Wenn es nicht ausgewählt wird, kann die Kubernetes API automatisch externe Loadbalancer und öffentliche IPs erstellen. Achten Sie darauf, dass Ihre Workloads gegenüber externen Angriffen oder neugierigen Blicken nicht exponiert werden.
Was passiert, wenn Ihre Anwendung einen Bug bezüglich „Server-Side Request Forgery“ (SSRF) oder „Remote Code Execution“ (RCE) aufweist?
Gehen Sie übungsweise beide Szenarien und die Störungsreaktion eingehend durch, um sicher zu sein, dass Ihre Abwehr solide ist. Ergreifen Sie Sicherheitsmaßnahmen, um im Falle eines erfolgreichen SSRF- oder RCE-Angriffs die Auswirkungen zu begrenzen.
Wie kann man sich sonst noch gegen Bedrohungen für die Kubernetes Umgebung wappnen?
Halten Sie ein Bedrohungsmodell für die typischsten „Was-wäre-wenn“-Sicherheitsszenarien bereit. Skizzieren Sie schon vorab, wie Ihr Team auf eine Cluster-Störung, eine Insider-Bedrohung, einen Konfigurationsfehler oder ein Angriffsszenario reagieren könnte. Die Bedrohungsmodellierung kann dabei so förmlich oder formlos verlaufen, wie Sie es möchten. Für den Einstieg empfehlen wir den Blog „The Current State of Kubernetes Threat Modeling“ von Marco Lancini.
Sorgen Sie zudem dafür, dass alle Komponenten von Drittanbietern aktualisiert werden. Entfernen Sie alle Integrationen, die nicht erforderlich sind. Dashboards, Bibliotheken und Plugins gelten im Kubernetes Ökosystem alle als potenzielle Gefährder.
Kubernetes bietet ein aufregendes neues Ökosystem, aber ähnlich wie bei allen anderen Tools ist es dann am nützlichsten, wenn es sicher ist.
