Vorteile Kubernetes-nativer Sicherheit

Es gibt zwei Hauptansätze für die Containersicherheit: Container-zentriert und Kubernetes-nativ. 

Container-zentrierte Plattformen arbeiten auf Container-Ebene und konzentrieren sich auf die Sicherung von Container-Images und der Container-Runtime. Diese Tools bieten Steuerelemente auf Containerebene. Sie verwenden dazu Techniken wie Inline-Proxys oder Shims, um beispielsweise die containerübergreifende Kommunikation zu steuern.

Kubernetes-native Sicherheit wird auf der Kubernetes-Ebene ausgeführt. Sie leitet den Kontext von Kubernetes ab und überträgt Richtlinien in Kubernetes, damit Kubernetes sie durchsetzen kann.

Kubernetes-native Sicherheit basiert auf einer tiefen Integration mit Kubernetes, um den Kontext zu erfassen und die nativen Steuerelemente von Kubernetes zu nutzen. Diese Architektur verbessert die Sicherheit in zweierlei Hinsicht: Sie liefert umfassenden Kontext und Insights und erkennt Kubernetes-spezifische Bedrohungen.

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

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

• direkte Integration in den Kubernetes-API-Server, um aus erster Hand Einblick in Kubernetes-Workloads und -Infrastruktur zu erhalten
• eigenständige Auswertung von Schwachstellen in der Kubernetes-Software
• Sicherheitsfunktionen, einschließlich Richtlinienverwaltung, basierend auf Ressourcen innerhalb des Kubernetes-Objektmodells, einschließlich Deployments, Namespaces, Services, Pods und andere
• Analyse deklarativer Daten von Kubernetes-spezifischen Artefakten (wie etwa Workload-Manifesten) und Konfigurationen
• Höchstmögliche Durchsetzung integrierter Kubernetes-Sicherheitsfunktionen für mehr Automatisierung, Skalierbarkeit und Zuverlässigkeit
• Deployment und Ausführung als Kubernetes-Anwendung, einschließlich Integrationen und Unterstützung für gängige Tools in cloudnativen Toolchains

Kubernetes-native Sicherheit bietet eine transparente Konfiguration nicht nur für Ihre Container, sondern auch für Ihr Kubernetes-Deployment. 

Es ist auch wichtig zu verstehen, ob und wie Ihre Workloads isoliert sind. Kubernetes ermöglicht standardmäßig allen Deployments, mit allen anderen Deployments innerhalb und außerhalb ihrer Namespaces zu kommunizieren. Weitgehende Transparenz der Netzwerk-Richtlinieneinstellungen, vorzugsweise in einem visuellen Format. Kein Entziffern von Text in einer YAML-Datei mehr, um herauszufinden, 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 sowie die Einstellungen der Control-Plane-Komponenten gesperrt sind, und dass Best Practices befolgt werden. Der Zugriff muss auf die geringstmöglichen Berechtigungen beschränkt sein, die für die Ausführung Ihrer Anwendungen erforderlich sind.

Wie bei anderen Computing-Ressourcen entscheiden sich viele Unternehmen dafür, Kubernetes in der Cloud auszuführen. Sie haben mehrere Möglichkeiten, Kubernetes in der Cloud auszuführen:

• selbst gemanagtes Kubernetes
• kommerzielle Distribution von Kubernetes
• gemanagter Kubernetes Service

Für welches Modell Sie sich auch entscheiden, Sie und der Cloud-Anbieter „teilen" sich die Verantwortung für die Absicherung der Bereitstellung. Während bei Kubernetes – insbesondere bei verwalteten Kubernetes-Diensten – das typische Modell der geteilten Verantwortung gilt, kann es manchmal verwirrend sein, wo die Grenze in Bezug auf die Verantwortung für die Sicherheit gezogen wird.

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

Zu den Services gehört in der Regel das Einrichten der Control Plane und das Ermöglichen der Redundanz dieser Knoten. Dazu gehört oft die Ausführung in verschiedenen Regionen, um einen Ausfall zu verhindern, falls ein Teil der Infrastruktur des Cloud-Anbieters ausfällt.

Gewöhnlich bieten Cloud-Anbieter Folgendes:

• Kubernetes auf dem neuesten Stand halten
• Patches der Control Plane installieren
• Patches für das Node-OS liefern – hängt oft von der Wahl des OS ab
• Oft Container-optimierte Betriebssystem-Images für Knoten anbieten
• Manchmal Schwachstellen-Scanner anbieten. Dabei müssen Sie jedoch selbst die Richtlinie erstellen, wie etwa Verwendung eines Zugangscontrollers, um basierend auf den Scanergebnissen den Zugang zuzulassen/zu verweigern.

Der Kunde ist immer für die Absicherung des Kubernetes-Workloads verantwortlich, einschließlich dieser Sicherheitsaspekte:

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

Kubernetes-native Sicherheitsplattformen bieten mehrere entscheidende Vorteile. 

Erhöhter Schutz 

Kubernetes-native Sicherheit bietet umfassendere Insights, indem sie die deklarativen Daten von Kubernetes einbindet, um Schwachstellen in Kubernetes und Containern zu entdecken. 

Höhere operative Effizienz 

Die Verwendung des gleichen Frameworks für Infrastrukturmanagement und Sicherheit verkürzt die Lernkurve von Kubernetes, und der Kubernetes-Kontext ermöglicht eine schnellere Bedrohungserkennung und priorisierte Risikobewertungen.

Verringertes operatives Risiko 

Durch die Nutzung der nativen Steuerelemente von Kubernetes wird sichergestellt, dass auch bei der Sicherheit das Tempo und die Skalierbarkeit von Kubernetes vorherrschen. Wenn Richtlinien in Kubernetes eingebettet sind, gibt es keine Konflikte zwischen externen Kontrollen und dem Orchestrator.

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

Angesichts der steilen Lernkurve, die viele Benutzer mit Kubernetes durchlaufen, ist es leicht, Fehler zu machen. Ein solcher Fehler sind erhöhte Berechtigungen durch rollenbasierte Zugriffssteuerung (RBAC) in Kubernetes. Dabei kann Deployments ermöglicht werden, Secrets abzurufen, selbst wenn diese nicht benötigt werden.

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

Durch die direkte Einbettung von Sicherheitskontrollen in Kubernetes wird auch das Risiko einer separaten Kontrollsoftware beseitigt, die im Fehlerfall entweder den gesamten Anwendungsdatenverkehr ohne aktivierte Sicherheit zulassen (fail open) oder ihn abbrechen würde (fail closed).

Wenn der Kubernetes Orchestrator Richtlinienkontrollen durchsetzt, erhält die Sicherheit die gesamte Skalierbarkeit von Kubernetes, einschließlich der Palette der in Kubernetes enthaltenen Richtliniendurchsetzungsoptionen. 

Im Gegensatz dazu führt die Verwendung von Inline-Proxys oder Shims für die Durchsetzung zu Single Points of Failure, zu Skalierbarkeitsproblemen und zu Leistungseinschränkungen.

Mit Kubernetes können Sie beispielsweise Netzwerkrichtlinien anwenden, um Ihren Datenverkehr zu segmentieren. Sie können durch Zugangssteuerungen Richtlinien auf Anforderungen anwenden, die an den Kubernetes-API-Server gehen. Sie können Secrets zum Speichern vertraulicher Anmeldeinformationen formulieren, und Sie können die rollenbasierte Zugriffssteuerung (RBAC) anwenden, um bestimmte Funktionen für bestimmte Benutzer und Dienstkonten zu autorisieren.

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

Durch die Bereitstellung einer einzigen, einheitlichen Plattform für die Provisionierung und den Betrieb von Infrastruktur-Services optimiert und vereinheitlicht Kubernetes die Workflows in den Anwendungsentwicklungs- und Operations-Teams. 

Der gleiche konsolidierte Ansatz, bei dem alle an einem allgemeingültigen Datenbestand (source of truth) arbeiten und dieselbe Infrastruktur verwenden, kann sich auch auf die Sicherheit erstrecken, wenn Sie eine Kubernetes-native Sicherheitsplattform bereitstellen. 

Dieser Ansatz spart Zeit und Geld, indem er die Lernkurve verkürzt und eine schnellere Analyse und Behebung ermöglicht.

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

DevOps könnte eine Kubernetes-Netzwerkrichtlinie festlegen, die den Datenverkehr zwischen zwei Knoten zulässt, und die Sicherheit könnte eine Kontrolle über eine separate Steuerungssoftware einführen, die diesen Datenverkehr blockiert.

Ein Blick auf die Einstellungen in Kubernetes würde DevOps zeigen, dass die Anwendung mit fließendem Datenverkehr funktionieren sollte. Dabei könnte es völlig unklar bleiben, warum die App fehlschlägt, da die von der separaten Steuerungssoftware ausgeübten Kontrollen nicht sichtbar sind.

Wenn DevOps und Sicherheitsteams jedoch dieselben Konstrukte verwenden, um containerisierte Apps zu erstellen und zu versenden sowie diese zu sichern, müssen sie weniger Schnittstellen, Tools und Modelle lernen. 

DevOps verwendet Kubernetes-Manifest-Dateien, um die Ressourcen zu definieren, die eine bestimmte Anwendung benötigt. Die Verwendung derselben Assets, um den Sicherheitskontext zu ermitteln und Richtlinien anzuwenden, reduziert die Komplexität und verbessert das Sicherheitsergebnis. 

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

Darüber hinaus werden Sicherheitsprobleme direkt den Kubernetes-Objekten und -Ressourcen zugeordnet, die diese Teams täglich verwenden, was die Abläufe weiter vereinfacht.

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

Container erschweren die Sicherheit von cloudnativen Anwendungen in vielerlei Hinsicht. Vorfälle können sehr weit verbreitet sein, Container können große Datenmengen zur Verarbeitung produzieren, und sie sind kurzlebig, was die herkömmliche Reaktion auf Vorfälle obsolet macht.

Kubernetes-native Sicherheit ermöglicht Ihnen, Bedrohungen für Ihre Container präziser zu erkennen und den Zeit- und Arbeitsaufwand für eine effektive Umsetzung der Sicherheit in Ihrer Umgebung zu reduzieren.

Im Kontext von Kubernetes ist das erwartete Verhalten in jedem Fall klar. Infolgedessen kann die Kubernetes-native Sicherheit Anomalien mit höherer Genauigkeit erkennen, und Sie können Erzwingungsoptionen wie das Beenden eines Pods sicher anwenden.

Gleichzeitig reduziert die Verwendung von Kubernetes-Kontext auch False Positives und Alarmermüdung.

Kubernetes-native Sicherheit bietet außerdem die Möglichkeit, Sicherheitsaufgaben risikobasiert anzugehen. 

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

Die Zusammenführung verschiedener Aspekte der Kubernetes-Metadaten, wie etwa ob sich ein Cluster in Entwicklung oder Produktion befindet, ob er dem Internet ausgesetzt ist oder nicht, wie kritisch die Anwendung ist und ob derzeit verdächtige Prozesse darauf ausgeführt werden, zeigt Ihnen, was die Aufmerksamkeit Ihres Teams gerade jetzt erfordert. 

Das Erkennen von Kubernetes-spezifischen Schwachstellen, insbesondere solchen, die den Kubernetes-API-Server gefährden, ist besonders wichtig bei der Verhinderung, der Identifikation und der Behebung von Problemen. Kubernetes-native Sicherheitstools können diese Schwachstellen automatisch erkennen.

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

Die weit offene Beschaffenheit von Kubernetes-Deployments stellt einen weiteren Bedrohungsvektor dar. Da Kubernetes in erster Linie eine Plattform für Infrastrukturabläufe ist, sind nicht unbedingt alle Komponenten der operativen Einfachheit halber standardmäßig sicher. 

Die Anwendung von Kubernetes-Netzwerkrichtlinien zur Einschränkung der Kommunikation ist ein weiteres wichtiges Element bei der Sicherung Ihrer Kubernetes-Deployments. Kubernetes-native Sicherheitsplattformen können Ihre Netzwerkaktivitäten automatisch als Baseline verwenden. Dann können sie ermitteln, welche Kommunikationspfade für die Wartung Ihrer Anwendung erforderlich sind, und die richtige YAML-Datei erstellen, um den Umfang des Netzwerkzugriffs zu reduzieren.

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

Kubernetes-native Sicherheit ermöglicht eine hohe Portabilität und Wiederverwendung. Anhand eines einzigen, standardisierten Verfahrens, das dort ausgeführt wird, wo Kubernetes ausgeführt wird, wird sichergestellt, dass die Richtlinien in allen Umgebungen einheitlich angewendet werden. 

Mit Kubernetes-nativer Sicherheit können Nutzer eine einzelne Konfiguration festlegen, wie etwa eine Netzwerkrichtlinie, die für alle Pods in eines Deployments gelten soll, anstatt auf jedem Host in einem Cluster Steuerelemente auf Systemebene konfigurieren zu müssen. 

Durch die Einbindung von Richtlinien in CI/CD-Systeme und in das Kubernetes-Zulassungscontroller-Framework können Unternehmen Kontrollrichtlinien zu einem frühen Zeitpunkt im Softwareentwicklungs-Lifecycle einfacher anwenden und so Gefährdungen zur Laufzeit verhindern. 

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