Kubernetes-Operatoren können bei zustandslosen Anwendungen nützlich sein - allerdings müssen einige kritische Sicherheitsaspekte beachtet werden.
Wenn ein Hacker beispielsweise eine Schwachstelle in einem Nutzlast-Container ausnutzen kann, könnte er auch andere Container im selben Namensraum angreifen. Einer unserer Kunden war besorgt über die möglichen Auswirkungen auf die Sicherheit, so dass unser Team entschied, dass wir die Sicherheitsrisiken von Betreibern näher untersuchen mussten.
Dieser Artikel befasst sich mit der Verwendung von Operatoren in einer produktionsbereiten Umgebung und den damit verbundenen Sicherheitsaspekten, die Sie berücksichtigen sollten, bevor Sie Kubernetes-Operatoren verwenden. Außerdem wird ein praktisches Beispiel mit einem Zertifikatsmanager-Operator vorgestellt.
Wie Operatoren funktionieren
Bevor wir über Sicherheit sprechen, sollten wir die Funktionsweise von Operatoren erläutern. Einfach ausgedrückt: Operatoren rationalisieren und vereinfachen die Arbeit mit Kubernetes. Zunächst wird ein Operator-Pod bereitgestellt, der die Geheimnisse des jeweiligen Benutzers enthält, die für eine effektive Kommunikation zwischen dem Operator-Pod und dem etcd erforderlich sind. Dieser Lese- und Schreibzugriff auf Informationen innerhalb des etcd ist möglich (sofern die spezifischen Zugriffsrechte des Benutzers gegeben sind).
Unter bestimmten Umständen kann ein Benutzer benutzerdefinierte Ressourcendefinitionen (CRD) innerhalb des etcd erstellen, die Schemata für die Bereitstellung von Ressourcen im Cluster enthalten können. Mit dem Befehl kubectl kann ein Benutzer diese CRDs aktivieren und die Dateien im etcd speichern. Von dort aus können Operatoren von der neuen Datei im etcd ausgelöst werden und über die kube-API eine Bereitstellung im Cluster erstellen.
Die Funktionsweise ist in der folgenden Abbildung dargestellt.
Risiken für den Betreiber und Präventivmaßnahmen
Das größte Sicherheitsrisiko bei Operator-Pods ist ihre angeborene Fähigkeit, andere Pods einzusetzen. Selbst ein Operator-Pod mit geringen Rechten kann einen Pod mit höheren Rechten als sich selbst bereitstellen. Aufgrund der Funktionsweise von Kubernetes können Pods direkt miteinander kommunizieren und eine Eskalation der Sicherheitsrisiken auslösen. Im schlimmsten Fall kann sogar der Host-Rechner betroffen sein. Deshalb ist eine strikte Trennung zwischen der Anwendung, die vom Operator bereitgestellt wird, und dem Operator selbst erforderlich.
Grundlegende Prävention
Operatoren sind Pods, die direkt mit der Kubernetes-API kommunizieren können. Operatoren sollten keinen oder bei Bedarf nur einen eingeschränkten Internetzugang haben. Payloads sind Pods, die nicht direkt mit der Kubernetes-API kommunizieren können. Payloads können bei Bedarf auf das Internet zugreifen und auch aus dem Internet angesprochen werden.
Angesichts der Risiken für die Betreiber ist es von Vorteil, einige bewährte Sicherheitsverfahren anzuwenden. Diese Best Practices sollen das Potenzial von Kubernetes-Betreibern einschränken, abtrünnig zu werden und als Teil von Hacker-Strategien eingesetzt zu werden.
Strategien zur Risikoreduzierung bei der Verwendung von Kubernetes-Operatoren
1. Nutzlast und Bediener getrennt halten
Bei der Verwendung von Netzwerkrichtlinien sollten die Namensräume strikt getrennt sein und der Operator-Namensraum sollte keine Nutzlast-Pods enthalten. Außerdem sollte sich die Nutzlast in einem anderen Namespace befinden als der Operator. Eine fehlerhafte Trennung der Namespaces ermöglicht es dem Betreiber, Pods einzusetzen, die auf Pods in anderen Namespaces zugreifen können.
2. Die API unter Quarantäne stellen
Da der Betreiber mit der API kommunizieren kann, während er erhöhte Rechte verwendet und Pods bereitstellt, ist dies ein beliebter Angriffsvektor und stellt eine erhebliche Bedrohung für die Sicherheit dar, wenn er nicht ordnungsgemäß über Ihre Netzwerkrichtlinien verwaltet wird.
3. Benennen Sie ein Servicekonto für den Betreiber
Mit einem minimalistischen Dienstkonto ist der Betreiber in der Lage, die Nutzlast in dem vorgesehenen Namensraum bereitzustellen und gleichzeitig andere Namensräume vor möglichen Sicherheitsrisiken zu schützen.
4. Verhindern, dass der Betreiber PSPs und PSAs erstellt
Indem Sie Betreiber daran hindern, neue Netzwerkrichtlinien zu erstellen, können Sie das Risiko einer Zugriffseskalation proaktiv verringern. Durch die Verwendung eines selbst erstellten PSP könnte der Operator einen Pod bereitstellen, der eine Eskalation der Privilegien auslöst, die sich sogar auf den Host-Rechner auswirken könnte. Operatoren sollten nur in ihrem eigenen Namensraum Netzwerkrichtlinien erstellen können und nirgendwo sonst. Nur Admins sollten in der Lage sein, PSPs (Pod-Sicherheitsrichtlinien) und PSAs (Pod-Sicherheitszulassungen) zu erstellen.
Wenn der Betreiber die Möglichkeit erhält, Pod-Sicherheitsrichtlinien zu erstellen, kann dies weitreichende Folgen haben. Bei der Pod-Bereitstellung sollten Sie immer die Pod-Sicherheitsrichtlinie mit den geringsten Einschränkungen wählen.
5. Beschränkung der Erstellung von CRDs durch den Betreiber
Der Einsatz eines Admission Controllers im Operator-Namensraum zur Verweigerung der Erstellung benutzerdefinierter Ressourcendefinitionsobjekte (Custom Resource Definition, CRD) ist notwendig, um zu verhindern, dass der Operator seine eigenen Privilegien ausbaut oder Payloads einsetzt.
6. Verwendung einer benutzerdefinierten Ressource zur Überprüfung der zugewiesenen Rechte
Durch die Kontrolle und Validierung zugewiesener Rechte kann verhindert werden, dass Software-Ressourcen Dienstkonten missbrauchen. Eine benutzerdefinierte Ressource (CR) kann verwendet werden, um zugewiesene Rechte jederzeit zu validieren. Mit diesen Strategien können Sie Ihre Bediener schützen, indem Sie ihnen den Zugang und die Berechtigungen geben, die sie benötigen, um ordnungsgemäß zu arbeiten, und gleichzeitig die Wahrscheinlichkeit verringern, dass sie für einen Einbruch und eine Eskalation des Zugangs ausgenutzt werden.
Ein Beispielszenario: Zertifikat-Manager
In diesem Abschnitt wird ein Beispieloperator mit der Rolle des Zertifikatsmanagers gezeigt und wie eine Schwachstelle ausgenutzt werden kann, um die Kontrolle über einen Container zu erlangen.
Der Cert-Manager muss auf Geheimnisse zugreifen, um wie vorgesehen zu funktionieren, aber dieser Zugriff macht ihn potenziell angreifbar. Wenn ein Hacker in der Lage ist, eine Schwachstelle im Nutzlast-Container auszunutzen, kann er möglicherweise auch andere Container im selben Namensraum angreifen. Ein Cert-Manager-Fehler kann beispielsweise dazu benutzt werden, die Kontrolle über seinen Container zu erlangen. Da der Cert-Manager (Operator) Zugriff auf die Kubernetes-API hat, könnte ein Hacker in der Lage sein, auch die API anzugreifen. Das bedeutet, dass er Zugang zu den Geheimnissen erlangen könnte.
Durch den Zugriff auf die Geheimnisse könnte er Zugang zu Dienstkonten mit höheren Privilegien erhalten. Mit diesen Rechten könnte er höher privilegierte Pods starten, was zu einer Privilegieneskalation führen würde. Sollte es keine PSPs geben, die den Zugriff auf privilegierte Container verhindern, könnte er sogar den Host übernehmen.
Die folgende Abbildung zeigt die Trennung der Namensräume.
Wir hoffen, dass Sie bei der Betrachtung dieses Beispiels erkennen, wie verwundbar dieser Cert-manager-Operator ist. Ein Hacker nutzte eine bereits vorhandene Schwachstelle und manipulierte einen Fehler, um die Kontrolle über den Container und schließlich die API selbst zu erlangen. Da das potenzielle Risiko real ist, sollten der Zugriff und die Berechtigungen von Kubernetes-Betreibern entsprechend eingeschränkt und verwaltet werden. Die Anwendung von Best Practices für die Sicherheit der Betreiber ist ein sinnvoller erster Schritt zur Verringerung dieser Risiken.
