Die Vorteile Kubernetes-nativer Sicherheit

Es gibt 2 Hauptansätze für die Containersicherheit: containerzentriert und Kubernetes-nativ. 

Containerzentrierte Plattformen arbeiten auf Containerebene und konzentrieren sich auf die Sicherung von Container-Images und der Container-Laufzeit. Diese Tools bieten Kontrollen auf der Containerebene, indem sie beispielsweise Techniken wie Inline-Proxies oder Shims zur Steuerung der containerübergreifenden Kommunikation einsetzen.

Die Kubernetes-native Sicherheit arbeitet auf der Kubernetes-Ebene. Sie bezieht den Kontext aus und überträgt Richtlinien an Kubernetes, damit diese von Kubernetes durchgesetzt werden können.

Kubernetes-native Sicherheit basiert auf einer tiefen Integration mit Kubernetes, um Kontextinformationen abzurufen und die nativen Steuerungsfunktionen von Kubernetes zu nutzen. Diese Architektur verbessert die Sicherheit in zweierlei Hinsicht, indem sie umfangreiche Kontextinformationen und Einblicke bereitstellt und Kubernetes-spezifische Bedrohungen erkennt.

Kubernetes-native Sicherheit basiert auf dem Prinzip, dass Sicherheit am effektivsten implementiert wird, wenn sie auf das System abgestimmt ist, das die containerisierten Anwendungen verwaltet. 

Eine Sicherheitsplattform muss die folgenden Eigenschaften aufweisen, um als Kubernetes-nativ angesehen zu werden:

• Direkte Integration mit dem Kubernetes-API-Server, um direkten Einblick in die Workloads und die Infrastruktur von Kubernetes zu erhalten
• Auswertung von Schwachstellen in der Kubernetes-Software selbst
• Sicherheitsfunktionen, einschließlich Richtlinienverwaltung, basierend auf Ressourcen innerhalb des Kubernetes-Objektmodells, einschließlich Deployments, Namespaces, Services, Pods und weitere
• Analyse deklarativer Daten von Kubernetes-spezifischen Artefakten (wie Workload-Manifesten) und Konfigurationen
• Verwendung integrierter Kubernetes-Sicherheitsfunktionen zur Durchsetzung, wann immer möglich, für mehr Automatisierung, Skalierbarkeit und Zuverlässigkeit
• Deployment und Ausführung als Kubernetes-Anwendung, einschließlich Integrationen und Support für gängige Tools in cloudnativen Toolchains

Die Kubernetes-native Sicherheit bietet Transparenz hinsichtlich der Konfiguration nicht nur Ihrer Container, sondern auch Ihres Kubernetes-Deployments. 

Es ist auch wichtig zu verstehen, wie oder ob Ihre Workloads isoliert sind. Kubernetes erlaubt standardmäßig allen Deployments, mit allen anderen Deployments innerhalb und außerhalb ihrer Namespaces zu kommunizieren. Ein detaillierter Einblick in die Einstellungen der Netzwerkrichtlinien, vorzugsweise in einem visuellen Format anstelle des Lesens einer YAML-Datei zeigt, welche Workloads nicht isoliert sind.

Um Ihre allgemeine Sicherheitslage zu verstehen, müssen Sie sicherstellen, dass Kubernetes-Konfigurationen wie Rollenberechtigungen, Zugriff auf Secrets, zulässiger Netzwerkverkehr und die Einstellungen der Control Plane-Komponenten gesperrt sind, den Best Practices entsprechen und auf die für die Ausführung Ihrer Anwendungen erforderlichen Mindestberechtigungen beschränkt sind.

Erfahren Sie mehr über Container-Sicherheit von der Entwicklung über die Bereitstellung bis zum Betrieb.

Genau wie bei anderen Rechenressourcen entscheiden sich viele Unternehmen dafür, Kubernetes in der Cloud auszuführen. Sie haben mehrere Möglichkeiten zur Ausführung von Kubernetes in der Cloud:

• Selbst gemanagtes Kubernetes
• Kommerzielle Distribution von Kubernetes
• Gemanagter Kubernetes-Service

Unabhängig davon, für welches Modell Sie sich entscheiden, teilen Sie sich die Verantwortung für die Sicherheit der Bereitstellung mit dem Cloud-Anbieter. Während bei Kubernetes – insbesondere bei verwalteten Kubernetes-Diensten – das typische Modell der geteilten Verantwortung gilt, kann es manchmal unklar sein, wo genau die Grenze der Verantwortung für die Sicherheit liegt.

Bei gemanagten Kubernetes-Diensten verwaltet der Cloud-Anbieter die Kubernetes-Control Plane, die die Kubernetes-Komponenten umfasst, welche den Cluster steuern, sowie Daten zu Status und Konfiguration des Clusters.

Zu den Diensten gehören in der Regel die Einrichtung der Control Plane, die Aktivierung der Redundanz dieser Knoten, häufig einschließlich ihres Betriebs in verschiedenen Regionen, um einen Ausfall zu verhindern, falls ein Teil der Infrastruktur des Cloud-Anbieters ausfallen sollte.

Gewöhnlich übernehmen Cloud-Anbieter folgende Punkte:

• Kubernetes auf dem neuesten Stand halten
• Patches der Control Plane durchführen
• Patchen des Knoten-Betriebssystems ermöglichen – oft abhängig von Ihrer Wahl des Betriebssystems
• Containeroptimierte Betriebssystem-Images für Knoten anbieten (häufig)
• Schwachstellenscanner bereitstellen, deren Richtlinien Sie erstellen müssen, wie etwa mithilfe eines Admission Controllers, um basierend auf den Scanergebnissen Zugriff zu gewähren oder zu verweigern

Der Kunde ist stets für die Sicherheit der Kubernetes-Workloads verantwortlich, einschließlich folgender Aspekte:

• Container Images: Quellen, Inhalte und Schwachstellen
• Deployments: Netzwerkservices, Storage und Berechtigungen
• Konfigurationsmanagement: Rollen, Gruppen, Rollenbindungen, Service-Accounts
• Anwendung: Secrets-Management, Labels und Annotations
• Netzwerksegmentierung: Netzwerkrichtlinien im Cluster
• Runtime: Bedrohungserkennung und Incident Response

Was sind SPIFFE und SPIRE?

Plattformen für Kubernetes-native Sicherheit bieten mehrere wesentliche Vorteile. 

Mehr Schutz 

Die Kubernetes-native Sicherheit bietet umfassendere Einblicke, indem sie sich in die deklarativen Daten von Kubernetes einbindet, um Schwachstellen in Kubernetes und Containern aufzudecken. 

Höhere operative Effizienz 

Die Verwendung desselben Frameworks für Infrastrukturmanagement und Sicherheit senkt die Lernkurve für Kubernetes. Der Kubernetes-Kontext ermöglicht eine schnellere Erkennung von Bedrohungen und priorisierte Risikobeurteilungen.

Reduziertes operatives Risiko 

Mit der Nutzung der nativen Kontrollen von Kubernetes wird sichergestellt, dass die Sicherheit mit dem Tempo und der Skalierbarkeit von Kubernetes Schritt hält. Durch die Einbettung von Richtlinien in Kubernetes gibt es keine Konflikte zwischen externen Kontrollen und dem Orchestrator.

Kubernetes-native Sicherheit hilft, operative Probleme zu reduzieren, die auf inkonsistente Konfiguration, mangelnde Koordination und Benutzerfehler zurückzuführen sind.

Angesichts der Lernkurve, die die meisten Nutzenden mit Kubernetes durchlaufen, können leicht Fehler vorkommen, wie etwa die Vergabe erhöhter Berechtigungen mithilfe der rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes, beispielsweise indem einem Nutzenden oder Service Account vollständige Cluster-Administratorrechte gewährt werden, oder die unnötige Offenlegung von Kubernetes Secrets, wenn Deployments so konfiguriert werden, dass sie Secrets abrufen, auch wenn diese nicht benötigt werden.

Kubernetes-native Sicherheitsplattformen können diese Fehlkonfigurationen automatisch und kontinuierlich identifizieren.

Die direkte Einbettung von Sicherheitskontrollen in Kubernetes beseitigt auch das Risiko einer separaten Kontrollsoftware, die bei einem Ausfall entweder offen versagen und den gesamten Datenverkehr ohne Sicherheitsmaßnahmen zulassen oder geschlossen versagen und den gesamten anwendungsbezogenen Datenverkehr unterbrechen würde.

Die Durchsetzung von Richtlinienkontrollen durch den Kubernetes-Orchestrator bedeutet, dass die Sicherheit sofort die gesamte Skalierbarkeit von Kubernetes selbst sowie die damit verbundenen vielfältigen Optionen zur Durchsetzung von Richtlinien nutzt. 

Im Gegensatz dazu führt die Verwendung von Inline-Proxies oder Shims zur Durchsetzung zu Single Points of Failure, Skalierbarkeitsproblemen und eingeschränkter Performance.

Mit Kubernetes können Sie beispielsweise Netzwerkrichtlinien anwenden, um Ihren Datenverkehr zu segmentieren, Admission Controller verwenden, um Richtlinien auf Anfragen an den Kubernetes-API-Server anzuwenden, Secrets zum Speichern sensibler Zugangsdaten verwenden und Role-based Access Control anwenden, um bestimmten Nutzenden und Service Accounts bestimmte Funktionen zuzuweisen.

Sie können auch zusätzliche standardisierte Tools verwenden, wie Netzwerk-Plugins, die der CNI (Container Network Interface) in Verbindung mit der Kubernetes-nativen Sicherheitsplattform entsprechen, und diese zusätzlichen Tools nach Bedarf ändern.

Durch die Bereitstellung einer einzelnen, einheitlichen Plattform für die Provisionierung und den Betrieb von Infrastrukturdiensten optimiert und vereinheitlicht Kubernetes die Arbeitsabläufe zwischen Anwendungsentwicklungs- und Operations-Teams. 

Derselbe konsolidierte Ansatz, bei dem alle mit einer gemeinsamen Datenquelle arbeiten und dieselbe Infrastruktur nutzen, lässt sich auch auf die Sicherheit ausweiten, wenn Sie eine Kubernetes-native Sicherheitsplattform einsetzen. 

Dieser Ansatz spart Zeit und Geld, indem er die Lernkurve senkt und eine schnellere Analyse und Problemlösung ermöglicht.

Wenn DevOps- und Sicherheitsteams unterschiedliche Tools verwenden, kann es leicht zu Konflikten bei deren Konfiguration kommen. 

DevOps kann eine Kubernetes-Netzwerkrichtlinie festlegen, die den Datenverkehr zwischen 2 Knoten zulässt, und das Sicherheitsteam könnte über eine separate Kontrollsoftware eine Kontrolle einführen, die diesen Datenverkehr blockiert.

Ein Blick auf die Einstellungen in Kubernetes würde DevOps zeigen, dass die Anwendung mit laufendem Datenverkehr funktionieren sollte. Trotzdem könnten sie ganz einfach nicht wissen, warum die App ausfällt, da sie die von der separaten Steuerungssoftware ausgeübten Kontrollen nicht sehen können.

Wenn DevOps- und Sicherheitsteams dieselben Konstrukte zum Entwickeln und Bereitstellen containerisierter Anwendungen sowie zu deren Sicherung verwenden, müssen sie weniger Schnittstellen, Tools und Modelle erlernen. 

DevOps verwendet Kubernetes-Manifestdateien, um die Ressourcen zu definieren, die eine bestimmte Anwendung benötigt. Die Verwendung derselben Ressourcen zur Ermittlung des Sicherheitskontexts und zur Anwendung von Richtlinien reduziert die Komplexität und verbessert die Sicherheit. 

Kubernetes-native Sicherheit behandelt Kubernetes als die Source of Truth für Sicherheitsrichtlinien, und alle – Sicherheits-, Operations- und DevOps- sowie SRE (Site Reliability Engineering)-Teams – arbeiten auf derselben Basis. 

Darüber hinaus lassen sich Sicherheitsprobleme direkt auf die Kubernetes-Objekte und -Ressourcen abbilden, die diese Teams täglich verwenden, was Abläufe weiter vereinfacht.

Vermeiden Sie das mit der Implementierung separater Sicherheitssoftware verbundene operative Risiko, indem Sie für Ihre Sicherheitsrichtlinien die Kubernetes-native Durchsetzung nutzen.

Container erschweren die Sicherheit für cloudnative Anwendungen in vielerlei Hinsicht, unter anderem weil Vorfälle sehr weit verstreut sein können, Container große Datenmengen zur Verarbeitung produzieren und sie kurzlebig sind, was herkömmliche Maßnahmen zur Reaktion auf Vorfälle überflüssig macht.

Mit Kubernetes-nativer Sicherheit können Sie Bedrohungen für Ihre Container genauer erkennen und den für die effektive Umsetzung von Sicherheitsmaßnahmen in Ihrer Umgebung erforderlichen Zeit- und Arbeitsaufwand reduzieren.

Im Kubernetes-Kontext ist das erwartete Verhalten klar. So kann die Kubernetes-native Sicherheit Anomalien mit höherer Genauigkeit erkennen, und Sie können Durchsetzungsoptionen wie das Abschalten eines Pods zuverlässiger anwenden.

Gleichzeitig reduziert die Verwendung des Kubernetes-Kontexts auch Falschmeldungen und Alarmmüdigkeit.

Die Kubernetes-native Sicherheit bietet auch die Möglichkeit, einen risikobasierten Ansatz für Sicherheitsaufgaben zu verfolgen. 

Ihre Deployments enthalten wahrscheinlich eine Reihe von Richtlinienverstößen, aber wo fangen Sie an? Auch hier hilft es, den Kubernetes-Kontext zu nutzen. 

Durch die Zusammenführung verschiedener Aspekte der Kubernetes-Metadaten, wie beispielsweise, ob sich ein Cluster in der Entwicklung oder in der Produktion befindet, ob er mit dem Internet verbunden ist oder nicht, wie kritisch die Anwendung ist und ob derzeit verdächtige Prozesse darauf laufen, wird deutlich, worauf Ihr Team derzeit besonders achten muss. 

Das Erkennen von Kubernetes-spezifischen Schwachstellen, insbesondere solchen, die den Kubernetes-API-Server gefährden, ist besonders wichtig, um diese zu verhindern, zu identifizieren und zu beseitigen. Kubernetes-native Sicherheitstools können diese Schwachstellen automatisch identifizieren.

Die Integration mit dem Kubernetes-API-Server bietet Sicherheitsüberwachung sowohl für die in Kubernetes-Clustern ausgeführten Container als auch für Kubernetes-Ressourcen wie Deployments, Daemon-Sets, Services, Pods und andere Ressourcen.

Die sehr offene Beschaffenheit von Kubernetes-Deployments stellt einen weiteren Bedrohungsvektor dar. Da Kubernetes in erster Linie eine Plattform für den Infrastrukturbetrieb ist, sind nicht alle Komponenten, die die Bedienung vereinfachen sollen, standardmäßig sicher. 

Die Anwendung von Kubernetes-Netzwerkrichtlinien zur Einschränkung der Kommunikation ist ein weiteres wichtiges Element für die Sicherheit Ihrer Kubernetes-Deployments. Kubernetes-native Sicherheitsplattformen können automatisch eine Baseline Ihrer Netzwerkaktivitäten erstellen, die für den Betrieb Ihrer Anwendung erforderlichen Kommunikationspfade identifizieren und die richtige YAML-Datei erstellen, um den Umfang des Netzwerkzugriffs zu reduzieren.

Mit den automatischen Sicherheitseinstellungen einer Kubernetes-nativen Plattform können Sie Bedrohungen auf der Kubernetes-Ebene kontinuierlich identifizieren und stoppen.

Kubernetes-native Sicherheit ermöglicht außerdem eine hohe Portierbarkeit und Wiederverwendbarkeit. Durch die Verwendung eines einzigen, standardisierten Ansatzes, der überall dort zum Einsatz kommt, wo Kubernetes läuft, wird die konsistente Anwendung von Richtlinien in allen Umgebungen sichergestellt. 

Nutzende können mit Kubernetes-nativer Sicherheit eine einzelne Konfiguration festlegen, wie eine Netzwerkrichtlinie, die für alle Pods in einem Deployment gelten soll. So ist es nicht mehr notwendig, Kontrollen auf Systemebene für jeden Host in einem Cluster zu konfigurieren. 

Durch das Binden von Richtlinien an CI/CD-Systeme und das Kubernetes Admission Controller Framework können Unternehmen Kontrollrichtlinien einfacher und früher im Softwareentwicklungs-Lifecycle anwenden und so Sicherheitsverletzungen zur Runtime vermeiden. 

Durch die Nutzung von Kubernetes-Konstrukten wie Admission Controller bleibt die Sicherheit tief in die Kubernetes-Toolchains eingebunden.

Kubernetes für Unternehmen testen