Was ist Kubernetes-Sicherheit?

Kubernetes, auch bekannt als K8s oder „Kube“ ist eine quelloffene Container-Orchestrierungsplattform, mit der Deployment, Management und Skalierung von containerisierten Anwendungen automatisiert werden können. Kubernetes organisiert Linux-Container in Clustern und verwendet APIs (Application Programming Interfaces), um containerisierte Microservices zu vernetzen. Da jede Schicht oder jeder Service in einer Kubernetes-Bereitstellung Schwachstellen aufweisen kann, ist der Prozess zur Sicherung eines Kubernetes-Clusters oft komplex. 

Während sich manche Teams bei ihrer Kubernetes-Sicherheit für einen containerzentrierten Ansatz entscheiden, der sich hauptsächlich auf die Sicherung von Container-Images und Container-Runtime konzentriert, wählen andere eine Kubernetes-native Sicherheit, die einen breiteren Ansatz verfolgt und Kontext von Kubernetes sowie integrierten Kubernetes-Kontrollfunktionen nutzt, um risikobasierte Best Practices im Bereich Sicherheit im gesamten Anwendungsentwicklungs-Lifecycle zu implementieren. Kubernetes-native Sicherheit beseitigt außerdem Risiken und Schwachstellen, die speziell bei Kubernetes auftreten, wie z. B. falsch konfigurierte Kubernetes-RBAC-Richtlinien, unsichere Komponenten in der Control Plane von Kubernetes sowie falsch verwendete Kubernetes-Secrets.

Kubernetes Pod-to-Pod-Networking

Ein großer Vorteil von Kubernetes ist seine große Bandbreite an Optionen zur Netzwerkkonfiguration, die kontrollieren, wie Pods innerhalb eines Clusters kommunizieren. Kubernetes kann jedoch nicht standardmäßig die Netzwerkkommunikation zwischen Pods einschränken, weshalb ein Pod mit anderen Pods kommunizieren kann, bis eine relevante Netzwerkrichtlinie zugewiesen wurde. Das bedeutet, dass ein einziger Pod, der von einem Angreifer gehackt wurde, als Vektor verwendet werden kann, um die anderen Pods in diesem Cluster anzugreifen. Kubernetes-Netzwerkrichtlinien werden mithilfe von YAML-Dateien geschrieben. Dies ist nur einer von vielen Gründen, warum die Operationalisierung von Kubernetes-Netzwerkrichtlinien schwierig sein kann, was dazu führt, dass zugunsten der Schnelligkeit auf die Netzwerksegmentierung verzichtet wird. 

Konfigurationsmanagement

Fehlkonfigurationen, die oft durch menschliches Versagen und den Mangel an automatisierten Sicherheitsscans ausgelöst werden, stellen ein ernsthaftes Risiko für Kubernetes-Umgebungen dar und können zu Angriffen führen. Aufgrund der dynamischen Natur von Containern ist es eine Herausforderung, Fehlkonfigurationen zu erkennen und eine konsistente Sicherheitslage aufrechtzuerhalten. Kubernetes wurde mit einem Fokus auf Schnelligkeit und Bedienbarkeit entwickelt, weshalb die Standardkonfigurationen normalerweise offen und nicht beschränkt sind. Das bedeutet, dass Unternehmen anfällig für Attacken sind.

Probleme in der Softwarelieferkette

Weiterhin sind Sicherheitsprobleme in der Softwarelieferkette, zu denen unter anderem anfällige Anwendungskomponenten, unzureichende Zugangskontrollen, ein Mangel an SBOM (Software Bill of Materials), Schwachstellen in der CI/CD-Pipeline und inkonsistente Richtliniendurchsetzungen zählen, ein große Herausforderung für Unternehmen. Die verzweigte Softwarelieferkette, für die cloudnative Kubernetes-Umgebungen bekannt sind, erfordern spezielle Kontrollfunktionen. Die Sicherheit der Softwarelieferkette muss in der IDE (Individual Developer Environment) beginnen und bis hin zur Runtime-Umgebung reichen. Sie muss alle Inhalte (Quellcode, Images, Artefakte), Tools (für Entwicklung und Sicherheit) und Menschen berücksichtigen, die Teil der Lieferkette sind. Die Analyse von Quellcode, Zugangskontrolle, Zertifizierung sowie SBOMs sind nur einige der vielen Aspekte, die bei der Sicherheit der Softwarelieferkette beachtet werden müssen. 

Sicherheit nach links verschieben

Eng mit der Sicherheit der Softwarelieferkette verbunden ist die Herausforderung, die Sicherheit nach links zu verschieben. Sicherheit nach links zu verschieben ist ein Konzept, das aussagt, dass Sicherheitsbemühungen in Kubernetes in die Anfangsphase des Container-Lifecycles verschoben werden sollten. Dies stellt eine Herausforderung dar, da nach links verschobene Sicherheit bedeutet, dass Entwicklungsteams zu Sicherheitsnutzenden werden müssen, welche das Wissen und die Tools besitzen, um innerhalb ihrer Workflows Sicherheitsentscheidungen zu treffen. Die geschäftlichen Vorteile einer nach links verschobenen Sicherheit sind jedoch enorm. Es handelt sich dabei um die Standardmethode, wie Kubernetes und Containersicherheit implementiert werden sollten. Je mehr Sicherheitsprobleme im Entwicklungsstadium gelöst werden, desto geringer ist die Wahrscheinlichkeit, dass Runtime-Probleme und Projektverzögerungen auftreten.

Erkennung und Reaktion der Runtime

Das Volumen an Runtime-Bedrohungsvektoren in containerisierten Anwendungen, die in einer Kubernetes-Umgebung ausgeführt werden, stellt eine Herausforderung für Teams dar, deren Aufgabe es ist, diese Probleme zu finden und auf sie zu reagieren. Es gibt viele Möglichkeiten, wie ein Angreifer zuerst Zugriff auf eine Kubernetes-Umgebung erhalten, schädlichen Code ausführen, Berechtigungen ausweiten, Persistenz erreichen, Erkennung entgehen und sich lateral bewegen kann. Dies kann zur Löschung oder Exfiltration von Daten, DOS (Denial of Service) oder der Übernahme von Ressourcen führen. Mehr Details über dieses Thema erfahren Sie in unserem Blog über das MITRE ATT&CK® Framework für Kubernetes. 

Kubernetes-Infrastruktursicherheit

Die vielen Schichten von Kubernetes, von Control Plane-Komponenten, darunter der API-Server, kube-scheduler und der kube-controller-manager, bis hin zu den Workerknoten-Komponenten, welche die containerisierten Workloads ausführen, haben ihre eigenen Sicherheitsherausforderungen. Jeder dieser Services muss sicher konfiguriert werden, damit eine gehärtete Cluster-Umgebung zur Ausführung von Anwendungen entsteht. Je nachdem, ob Sie Kubernetes als selbst gemanagten Service ausführen oder einen vollständig gemanagten Cloud Service verwenden, müssen Sie die verschiedenen Komponenten von Kubernetes unterschiedlich schützen. In selbst gemanagten Umgebungen unterliegt beispielsweise oftmals die Gesamtheit der Komponenten der Control Plane Ihrer Verantwortung – zusätzlich zu den Knoten. Wenn Sie einen gemanagten Kubernetes-Service nutzen, wird die Verantwortlichkeit für die Sicherheit zwischen dem Serviceanbieter und Ihnen, dem Kunden, geteilt. Dies stellt eine weitere Herausforderung dar.

Containerisierung und Kubernetes haben mehrere integrierte Sicherheitsvorteile, die Teams bei der Bewältigung von Risiken unterstützen, die mit Container-Sicherheitsproblemen einhergehen. Beispiele: 

• Container, deren Sicherheitsprobleme in der Runtime entdeckt werden, werden in der Entwicklungsphase behoben und neu bereitgestellt, anstatt diese während der Ausführung zu aktualisieren oder zu patchen. Diese Funktion wird auch als Unveränderlichkeit bezeichnet und ermöglicht eine bessere Vorhersagbarkeit von Container-Verhalten sowie Erkennung von ungewöhnlichem Verhalten. 
• Netzwerkrichtlinien können Pods oder Pod-Gruppen in Segmente unterteilen, während Zugangscontroller Richtlinien für eine bessere Governance anwenden können. 
• RBAC (Role-based Access Control) kann Nutzenden und Service-Accounts bestimmte Berechtigungen zuweisen.
• Kubernetes-Secrets können sensible Daten, wie etwa Verschlüsselungscodes, besser schützen.

Allerdings ist Kubernetes keine Sicherheitsplattform, weshalb Teams eine Risikobewertung durchführen und Schwachstellen in jeder Schicht der Kubernetes-Umgebung und in jeder Phase des Container- und Anwendungs-Lifecycles beheben müssen. Für den effektiven Umgang mit Kubernetes-Sicherheit müssen Sie, wenn verfügbar, die Vorteile von Kubernetes-nativen Sicherheitskontrollen nutzen und gleichzeitig Best Practices während den Entwicklungs-, Bereitstellungs- und Runtime-Phasen implementieren.

Red Hat ist führend in Open Source-Container-Technologie und kann Sie dabei unterstützen, Ihr Wissen über die Best Practices zur Kubernetes-Sicherheit zu erweitern und Ihre Container sicherer zu implementieren. Damit Teams Sicherheitsbedenken in K8s effizienter adressieren können, bietet Red Hat Kubernetes-native Lösungen an, die die Sicherheit in den Container-Lifecycle einbetten und es DevOps-Teams ermöglichen, produktionsbereite Anwendungen zu entwickeln und bereitzustellen.

Kubelinter, das von StackRox entwickelt und 2021 von Red Hat gekauft wurde, ist ein quelloffenes Tool für die statische Analyse, das Fehlkonfigurationen und Programmierfehler in Kubernetes-Deployments identifiziert. KubeLinter führt eine Reihe von Tests aus, um Kubernetes-Konfigurationen zu analysieren, Fehler zu identifizieren und Warnungen zu generieren, die auf die mangelnde Einhaltung von Best Practices im Bereich der Sicherheit hinweisen. 

Red Hat Service Interconnect bietet integrierte Sicherheit, die standardmäßig über Cluster und Clouds hinweg skaliert und gleichzeitig zuverlässige Kommunikationsverbindungen zwischen Services bereitstellt. Service Interconnect ermöglicht außerdem eine flexible Entwicklung auf Legacy-, Container- oder Kubernetes-Plattformen und bietet Ihren Entwicklungsteams mehr Optionen für das Entwickeln, Modernisieren und Bereitstellen Ihrer modernen Geschäftsanwendungen.

Mit Red Hat Advanced Cluster Security for Kubernetes (ACS) können Unternehmen sicherer cloudnative Anwendungen entwickeln, bereitstellen und ausführen. ACS ist als selbst gemanagte sowie als vollständig gemanagte SaaS-Lösung verfügbar und schützt containerisierte Workloads in nahezu allen bekannten Cloud- und Hybrid-Umgebung. DevOps- und InfoSec-Teams können damit Sicherheit operationalisieren, Betriebskosten senken und die Entwicklungsproduktivität erhöhen.