Cyberbedrohungen
Einblicke in die Kubernetes-Bedrohungsmodellierung
Kubernetes ist standardmäßig nicht gesichert. Bedrohungsmodellierung hilft, Sicherheitsprobleme frühzeitig zu erkennen und zu beheben. Dafür aber muss man die Hauptkomponenten verstehen und wissen, wie Angreifer diese nutzen können.
Save to Folio
Die meisten Unternehmen setzen mittlerweile die Container-Orchestrierungsplattform Kubernetes ein. Aber wie der Volksmund weiß, geht mit großer Stärke auch große Verantwortung einher. Und der Einsatz stellt die Anwender vor die Herausforderung, die Plattform und die komplexen Umgebungen, die damit verbunden sind angemessen abzusichern. Es gilt, zwei der Hauptprobleme in diesem Zusammenhang zu lösen, Sicherheitsstandards und Fehlkonfigurationen.
Mit Hilfe von Bedrohungsmodellierungstechniken lassen sich diese Probleme frühzeitig im Entwicklungslebenszyklus erkennen.
Bedrohungsmodellierung
Laut dem Threat Modeling Manifesto geht es darum, Systemdarstellungen zu analysieren, um Probleme der Sicherheits- und Datenschutzmerkmale aufzuzeigen. Über diesen Prozess der systematischen Identifizierung, Priorisierung und Dokumentation potenzieller Bedrohungen erhalten Systemdesigner und -architekten einen strukturierten Ansatz zur Identifizierung von Bedrohungen und Schwachstellen und zur Entwicklung geeigneter Sicherheitskontrollen zu ihrer Reduzierung. Bedrohungsmodelle helfen auch dabei, komplexe Risiken zu identifizieren und Datenflüsse für ein besseres Verständnis der Bedrohungen abzubilden.
Für die Durchführung der Bedrohungsmodellierung gibt es keine Einheitsmethode. Die Vielfalt und Komplexität von Systemen und Anwendungen lässt es nicht zu, einen Standard zu erstellen oder gar gängige Szenarien der Bedrohungsmodellierung zu automatisieren.
Der Microsoft Security Development Lifecycle (SDL), definiert fünf wichtige Schritte im Prozess:
- Definieren von Sicherheitsanforderungen
- Erstellen eines Anwendungsdiagramms
- Identifizieren von Bedrohungen
- Reduzierung von Bedrohungen
- Überprüfen, ob Bedrohungen gemindert wurden.
Diese fünf Schritte bilden einen systematischen Ansatz zur Identifizierung, Abwehr und Validierung von Bedrohungen. Vor allem die Analyse der Schichten von Cloud-nativen Systemen hilft bei der sachgerechten Durchführung dieser Schritte.
Die 4Cs von Cloud-nativen Systemen
Das Sicherheitsmodell von Cloud-nativen Systemen, zu denen Kubernetes gehört, ist so konstruiert, dass jedes der 4Cs – Cloud, Cluster, Container und Code – auf der vorhergehenden äußeren Schicht aufbaut. Daher wird die Cybersicherheit der Code-Ebene durch robuste Sicherheit an der Basis – in der Cloud-, Cluster- und Container-Ebene – verbessert.
Es ist wichtig, alle 4 Cs und nicht allein die Code-Ebene zu sichern, da Cybersicherheitsmaßnahmen allein auf Code-Ebene schwache Sicherheitsstandards in den anderen darunterliegenden Schichten nicht kompensieren kann. Stattdessen macht dies das gesamte System angreifbar.
Die Cluster-Komponenten
Das architektonische Design von Kubernetes beruht auf dem Prinzip von kurzlebigen und unabhängigen Objekten, die miteinander verknüpft sind.
Das Diagramm zeigt die beiden Hauptkomponenten eines Kubernetes-Clusters: die Steuerungsebene (Control Plane) und die Worker Nodes. Sie enthalten eine Reihe von Unterkomponenten.
Control Plane
Die Kubernetes-Steuerungsebene fungiert als Haupt-Node des Clusters und überwacht die Worker Nodes. Sie ist das zentrale Nervensystem und hält die komplizierte Struktur in einem funktionsfähigen und optimalen Zustand. Die einzelnen Bestandteile und deren Funktion beinhaltet der Originalbeitrag.
Worker Nodes
Worker-Node können in Analogie zur Steuerungsebene als Nervenzentrum als Muskelkraft des Systems bezeichnet werden. Sie führen alle Pods und Container innerhalb des Clusters aus und verwalten sie. Der Cluster kann zwischen null und vielen Worker-Node enthalten. Die wichtigsten Komponenten des WorkerNodes finden Sie im Originalbeitrag.
Ports und Protokolle
Das Verständnis der Ports und Protokolle, die von Kubernetes-Komponenten verwendet werden, kann beim Betrieb des Systems von Vorteil sein, insbesondere in einer Umgebung mit strengen Netzwerkparametern, wie z. B. einem physischen Rechenzentrum mit Netzwerk-Firewalls oder virtuellen Netzwerken innerhalb einer Public Cloud. Im Originalbeitrag finden Sie eine Zusammenfassung der Ports und Protokolle für die Steuerungsebene und die Worker Node.
Das Cluster-Bedrohungsmodell
Der Kube-API-Server
Der Kube-API-Server bietet Zugriff sowohl auf Benutzer als auch auf Servicekonten. Die gesamte Kommunikation wird über TLS verschlüsselt und standardmäßig über Port 6443 (443 für Managed Kubernetes) bereitgestellt.
Wir haben wiederholte Male vor den Gefahren von öffentlich zugänglichen Kubernetes-Clustern gewarnt.Ein Angreifer mit nicht authentifiziertem Zugriff auf den Kube API Server kann nicht viel ausrichten, es sei denn, es ist keine Authentifizierung aktiviert oder es gibt eine Schwachstelle im Cluster. Einige API-Endpunkte akzeptieren nicht authentifizierte (anonyme) API-Anfragen.
In diesem Fall beschränken die meisten Unternehmen ihren Cluster darauf, nur über bestimmte IP-Adressen oder CIDR-Bereiche (Classless Inter-Domain Routing) erreichbar zu sein, z. B. über ein virtuelles privates Netzwerk (VPN) oder das interne Netzwerk des Unternehmens. Dies reduziert die Angriffsfläche und begrenzt die Ausbreitung im Falle einer Kompromittierung.
Das Kubelet
Das Kubelet ist der Agent, der auf jedem Node sicherstellt, dass alle Container in einem Pod betriebsbereit sind. Er ist auch für die Implementierung von Änderungen an der Node-Konfiguration verantwortlich. Selbst der Master-Node betreibt einen Kubelet-Agenten (und einen Kube-Proxy), der die potenzielle Ausführung zusätzlicher Pods dort ermöglicht. Diese Vorgehensweise ist jedoch in der Regel nicht empfehlenswert, da die Container, auf denen Kubernetes ausgeführt wird, und die Container, die die Anwendungen des Benutzers verwalten, getrennt sein sollten.
Standardmäßig wird Port 10250 von der Kubelet-API verwendet und ist auf allen Nodes innerhalb eines Clusters geöffnet, wobei sowohl die Steuerungsebene des API-Servers als auch die Worker Node erfasst werden. In der Regel ist dieser Port nur intern sichtbar und kann von externen Diensten nicht erreicht werden. Abgesehen von jeder anderen Authentifizierungsmethode, die sie blockiert, werden Anforderungen an den API-Endpunkt des Kubelet standardmäßig als anonym betrachtet.
Die Sicherheitseinstellungen des Kubelets hängen von drei zentralen Elementen ab:
- Aktivieren der Kubelet-Authentifizierung. Anforderungen an den API-Endpunkt von Kubelet werden standardmäßig anonym gestellt, sofern sie nicht durch andere Authentifizierungsmethoden blockiert werden. Es ist ratsam, die Kubelets mit dem Flag --anonymous-auth=false zu starten, um den anonymen Zugriff zu deaktivieren.
- Einschränken von Kubelet-Berechtigungen, um Kubelet-Anmeldeinformationen zu schützen.
- Regelmäßiger Wechsel der Kubelet-Zertifikate. Bei einer Sicherheitsverletzung können diese kurzlebigen Zertifikate dazu beitragen, potenzielle Schäden zu begrenzen.
etcd
Etcd dient als primäres Speicherziel für den Cluster. Aufgrund seiner hierarchischen und standardisierten Struktur verwenden Kubernetes-Bereitstellungen etcd für die Beibehaltung von REST-API-Objekten und Installationskonfigurationen. Ein offengelegter etcd kann unbeabsichtigt zu erheblichen Datenlecks führen. Bedauerlicherweise sind falsch konfigurierte etcd-Instanzen nach wie vor weit verbreitet, wobei in diesem Jahr über 4.000 solcher exponierten Dienste auf Shodan zu finden waren.
Wenn ein Angreifer den API-Server umgeht und Objekte innerhalb von etcd direkt manipuliert, käme dies einem uneingeschränkten Zugriff auf den gesamten Cluster gleich. Der Eindringling könnte Pods erstellen, auf Geheimnisse zugreifen und vertrauliche Informationen wie Benutzer-Credentials anzeigen. Um dieses Risiko zu mindern, ist es wichtig, die Verschlüsselung während der Übertragung zu aktivieren und die Verschlüsselung ruhender Daten sicherzustellen, um Datenlecks oder unbefugte Änderungen an den etcd-Daten zu verhindern. Glücklicherweise bieten die meisten verwalteten Kubernetes-Dienste diese Option an oder aktivieren sie standardmäßig.
Ein weiterer Ansatz für die Bedrohungsmodellierung setzt auf MITRE ATT&CK für Container in der ersten Version von 2021, als Ergebnis einer Zusammenarbeit zwischen MITRE und dem Forschungsteam von Trend Micro veröffentlicht wurde. Der Originalbeitrag beinhaltet auch die MITRE ATT&CK für Container. Die Nutzung dieser Matrix kann Unternehmen dabei helfen, sich auf die häufigsten Schwachstellen zu konzentrieren, die Angreifer in diesen Umgebungen ausnutzen.
Einige Schwachstellen in Verbindung mit Container-Orchestrierung und Kubernetes:
- T1609 – Steuerung der Containerverwaltung.Mit den erforderlichen Berechtigungen kann ein Angreifer aus der Ferne über kube-apiserver, kubelet oder kubectl exec Befehle an einen Pod oder einen Container ausführen. Ein Bedrohungsakteur, der dies häufig ausnutzte, war TeamTNT. Um dies zu erkennen, ist es wichtig, die richtigen Protokolle, z. B. Kubernetes-Audit-Protokolle, auf verdächtige Befehlsausführungen zu überwachen.
- T1611 – Escape to Host. Ausbrechen aus den Container- oder Pod-Beschränkungen ist nichts Neues. Diese Technik zur Rechteausweitung kann einem Angreifer jedoch den Zugriff auf einen Worker Node oder sogar einen Node der Steuerungsebene ermöglichen, je nachdem, wie der Cluster eingerichtet ist. Laut MITRE könnte ein Angreifer durch den Zugriff auf den Host z. B. Persistenz, laterale Bewegung oder die Einrichtung eines Command-and-Control-Kanals (C&C) schaffen.
- T1613 – Container- and Ressourcenerkundung. Erkundung stellt eine der wichtigsten Techniken von Angreifern dar, um verschiedene Systeme zu kompromittieren. Angreifer nutzen Netzwerk- und Port-Scanning-Tools wie Nmap, masscan, zgrab und andere. Laut MITRE ist die Überwachung von Logs auf Aktionen zum Sammeln von Pod-Informationen, wie z. B. Erkennungsaufrufe durch verdächtige Benutzer, unerlässlich.
- T1610 – Bereitstellen eines Containers (oder Pods). Angreifer tun dies aus mehreren Gründen, vorausgesetzt, sie verfügen über die erforderlichen Berechtigungen. So geht es etwa um darum, einen privilegierten Pod aufzusetzen, um dem Host zu entkommen. Eines der häufigsten Szenarien, ist die Bereitstellung eines neuen Containers mit Kryptowährungs-Mining-Tools und das Mining von Kryptowährung, hauptsächlich Monero.