Die Zahl der Anwendungsfälle für Kubernetes nimmt zu, da immer mehr Unternehmen aus einer Vielzahl von Branchen Kubernetes als Plattform ihrer Wahl übernehmen. Dies erweitert jedoch auch die Angriffsfläche des Unternehmens und das Geschäftsrisiko.
Wir sprachen mit William, Morgan CEO von Heiter, wie CISOs mit der Unsicherheit konfrontiert werden, die aus der Verwaltung von Kubernetes-Plattformen entstehen kann. Sie beginnen, die Risiken zu erkennen, die sich entfalten können, und wie ein Service-Mesh einen Sicherheits-Stack unterstützen kann.
BN: Welche Branchen beginnen, Kubernetes als Plattform ihrer Wahl zu übernehmen, und warum Sehen wir diesen Anstieg?
WM: Unserer Erfahrung nach ist Kubernetes branchenübergreifend, und es ist eher eine Frage, ob ein Unternehmen in seinen Infrastruktur-Stack investiert, als in welcher Branche es tätig ist. Wir sehen Einführung von Linkerd – die Kubernetes als Voraussetzung erfordert – überall, von Banken (einschließlich traditioneller und „Internetbanken“) über Gastronomieunternehmen bis hin zu Krankenversicherungen und medizinischen Einrichtungen Diagnose-und Ausrüstungsunternehmen. Sogar Videospiele machen mit – das Microsoft Xbox Cloud-Team hielt dieses Jahr auf der Kubecon einen Vortrag über den massiven Linkerd-Einsatz in Kubernetes-Clustern auf der ganzen Welt, wobei der Hauptwert von Linkerd die Sicherheitsebene ist, die es basierend auf gegenseitigem TLS bietet.
BN: Inwiefern erweitert dies die Angriffsfläche des Unternehmens und das Geschäftsrisiko als Folge davon?
WM: Wie alle neuen Technologien führt Kubernetes neue Betriebs-und Sicherheitsoberflächen ein. Es ist zwar eine massive Verbesserung gegenüber dem Vorgänger, aber auch eine massive Änderung, und das bedeutet, dass die Techniken, Lektionen und Tools, die Organisationen in den Tagen vor Kubernetes gute Dienste geleistet haben, nicht unbedingt übersetzt werden können.
BN: Welche Risiken sollten CISOs im Auge behalten, wenn es um die Unsicherheit geht, die aus der Verwaltung von Kubernetes-Plattformen entstehen kann, und wie kann Service Mesh ihren Sicherheitsstack unterstützen?
WM: I würde argumentieren, dass die Sicherheitsvorteile, die ein Service-Mesh wie Linkerd bietet, nicht Probleme angehen, die sich aus der Verwaltung von Kubernetes-Plattformen selbst ergeben, sondern dass sie Sicherheitsprobleme angehen, die für die Cloud-Einführung überhaupt von grundlegender Bedeutung sind. Die Verschlüsselung von Daten bei der Übertragung zwischen Anwendungskomponenten ist ein hervorragendes Beispiel dafür. In der Vor-Cloud-Ära waren die Risikofaktoren rund um die interne Vernetzung ganz anders. Organisationen besaßen ihre eigene Netzwerkinfrastruktur und übten erhebliche Kontrolle darüber aus, sogar bis hin zu den Schlüsseln zu den Käfigen, die die Racks im Rechenzentrum schützten. In der Cloud-Umgebung ist diese Kontrollebene jetzt aus dem Fenster – die Netzwerkinfrastruktur wird von einem Drittanbieter betrieben und mit anderen Mietern geteilt. Was wir an Kontrolle über unsere Hardware verloren haben, muss jetzt über unsere Software zurückgewonnen werden, und Dinge wie die Verschlüsselung von Daten während der Übertragung sind plötzlich viel wichtiger. Und Kubernetes bietet uns Mechanismen, mit denen wir Tools wie Service Meshes erstellen können, die es uns ermöglichen, transparent eine starke Verschlüsselung – und Authentifizierung und Autorisierung – zwischen Anwendungskomponenten einzufügen, und zwar auf eine Weise, die einfacher und weitaus nahtloser als je zuvor ist.
BN: Wie unterstützt Service Mesh einen Zero-Trust-Ansatz für moderne Netzwerke und Infrastrukturen und hält Sicherheitsgrenzen ein?
WM: Zero-Trust ist eines der absoluten klarsten Anwendungsfälle für ein Service Mesh – zumindest ein Sidecar-basiertes Service Mesh. Das Ziel von Zero Trust ist es, überall und jederzeit zu verifizieren, und dies auf möglichst granularer Ebene. Der Service-Mesh-Ansatz geht dies direkt an, indem er in jedem Kubernetes-Pod einen Sidecar-Proxy platziert. Dieser Sidecar-Proxy wird dann zum Sicherheitserzwingungspunkt des Pods, führt seine eigene Authentifizierung, Autorisierung, Verschlüsselung usw. durch und enthält das gesamte kryptografische Schlüsselmaterial, das nur für diesen Pod erforderlich ist. In Linkerd sind unsere Sidecar-Proxys in der Programmiersprache Rust geschrieben, die auf Sicherheit ausgelegt ist und eine ganze Klasse von CVEs vermeidet, die in Sprachen wie C++ endemisch sind. Der Sidecar-Ansatz bedeutet, dass Linkerd jeder Kubernetes-Anwendung transparent hinzugefügt werden kann, in der Regel ohne zusätzliche Konfiguration, und sofort damit beginnen kann, eine Ebene der Autorisierung und Authentifizierung basierend auf gegenseitigem TLS bereitzustellen.
BN: How can CISOs minimieren Sicherheitsbedrohungen (Verstöße) und mindern Risiken?
WM: Die schlechte Nachricht für CISOs ist, dass Kubernetes brandneue Betriebs-und Sicherheitsmodelle einführt, mit denen sie sich jetzt auseinandersetzen müssen. Die gute Nachricht ist, dass Kubernetes auch für CISOs viele Dinge erheblich vereinfacht, insbesondere beim Umgang mit Sicherheitsrisiken, die der Cloud innewohnen – was sinnvoll ist, da Kubernetes die Säule des „Cloud-nativen“ Ansatzes ist, der für diese Umgebung entwickelt wurde. Das Service Mesh ist ein gutes Beispiel dafür. Auf der Makroebene bleibt die Geschichte für CISOs jedoch unabhängig von Kubernetes dieselbe: Um Sicherheitsbedrohungen zu minimieren und Risiken zu mindern, muss der CISO über klar definierte Bedrohungsmodelle verfügen; muss Verteidigung in der Tiefe bieten; und müssen mit dem sich schnell verändernden Ökosystem von Bedrohungen und Abwehrmaßnahmen Schritt halten und Wege finden, dies zu erreichen, ohne das Tempo der Geschäftsinnovation zu verlangsamen. Für CISOs ändert Kubernetes möglicherweise die Details, ändert aber letztendlich nicht das Gesamtbild.
Bildnachweis: Den Rise/Shutterstock