Maschinen-Identitäten in Kubernetes-Umgebungen Warum die mTLS-Authentifizierung von Istio Probleme birgt

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Mimecast Germany GmbH

Specops Software GmbH

Venafi Inc.

Für ihre Container- und Kubernetes-Umgebungen benötigen Unternehmen eine Service-Mesh-Schicht, über welche die Kommunikation der Microservices gewährleistet wird. Istio kommt in vielen Szenarien zum Einsatz, doch die Mutual-TLS-Authentifizierung der Plattform birgt Gefahren.

Container sind zentraler Bestandteil moderner Entwicklungsumgebungen. Sie bieten eine schlankere und portablere Architektur als virtuelle Maschinen (VMs), abstrahieren das Betriebssystem und liefern ein Softwarepaket, das alles enthält, was zur Ausführung in jeder Umgebung erforderlich ist. Weniger Overhead, größere Konsistenz und die Fähigkeit, in jeder Cloud zu laufen, haben sie zu einem Hit bei DevOps-Teams gemacht.

Die CNCF schätzt, dass die Akzeptanz von Containern in Unternehmen bis Ende 2022 im Vergleich zum Vorjahr um 49 Prozent steigen wird. Dieser Boom bei der Nutzung von Containern hat den Bedarf an einer Orchestrierungsplattform zur Verwaltung dieser Umgebungen entstehen lassen. Kubernetes hat sich in der Branche zum De-facto-Standard entwickelt, um sicherzustellen, dass Container gemäß den Spezifikationen ausgeführt werden und skalierbar sind.

Kubernetes wird inzwischen als die weltweit größte Orchestrierungsplattform für Container-Workloads bezeichnet – 83 Prozent der CNCF-Mitglieder setzten sie schon 2020 in der Produktion ein. Durch die Automatisierung von containerisierten Umgebungen ermöglicht Kubernetes eine dynamische, Multi-Cloud- und Multi-Open-Source-Umgebung, die zudem skalierbar, kosteneffizient und produktiv ist - ein Paradies für Entwickler. Mit der zunehmenden Reife von Kubernetes wuchs jedoch auch der Bedarf an mehr Kontrolle und Governance. Hier kommt Istio ins Spiel.

Istio wird zum Tool der Wahl, um einheitliche Beobachtbarkeit, betriebliche Agilität und richtliniengesteuerte Sicherheit in Cloud-nativen Kubernetes-Umgebungen zu gewährleisten, die sowohl in ihrer Größe als auch in ihrer Komplexität täglich zunehmen. Da Kubernetes immer ausgereifter wird und Unternehmen nun mehrere Cluster einsetzen, bietet Istio eine dringend benötigte Abstraktionsebene zur Verwaltung der Governance.

Die Bereitstellung eines Istio-Service-Mesh ist jedoch nichts für schwache Nerven. Um die Integrität dieser Umgebungen zu gewährleisten, muss der Datenverkehr zwischen Containern sicher sein. Dies erfordert ein starkes Identitätssystem, um die Integrität dieser Umgebungen zu gewährleisten. Ohne dieses System könnte Istio neue Risiken einführen, die das Potenzial haben, sich in automatisierten Umgebungen zu vervielfachen.

Warum brauchen wir ein Service Mesh wie Istio?

Istio hat sich zu einer beliebten Methode für Unternehmen entwickelt, um diese komplexen Kubernetes-Umgebungen in den Griff zu bekommen. Es fungiert als Service-Mesh-Schicht und bietet ein transparentes und sprachunabhängiges Framework, das einheitliche Beobachtbarkeit, Verkehrsmanagement und richtliniengesteuerte Sicherheit ermöglicht.

Istio wurde entwickelt, um Unternehmen das Leben zu erleichtern, indem es eine Aufgabe übernimmt, für die sonst mehrere Einzellösungen erforderlich wären. Das bedeutet, dass der Datenverkehr zu und von bestimmten Workloads innerhalb von Clustern und zwischen Clustern verwaltet wird. Es bedeutet eine einfachere Konfiguration von Service-Level-Eigenschaften wie Circuit Breakers, Timeouts und Retries.

Die Telemetrie ist außerdem sofort einsatzbereit, um eingehende und ausgehende Anfragen an und von jedem Kubernetes-Pod zu verwalten. Mit Istio brauchen Entwicklerteams das Produkt nur einmal zu installieren und können es für jeden Container, jede Workload und jede Anwendung verwenden, anstatt jedes Mal Lösungen zu entwickeln, wenn sie etwas in Gang setzen wollen

Trotz der großen Vorteile ist die Implementierung von Istio jedoch keine leichte Aufgabe. Die Einrichtung und Verwaltung von Istio kann erhebliche interne Fähigkeiten erfordern. Daher ist es in erster Linie eine Domäne großer Unternehmen, vor allem in regulierten Branchen, die über die notwendigen Ressourcen und strengen Compliance-Anforderungen verfügen, um dies zu gewährleisten.

Absicherung des internen Datenverkehrs mit Mutual TLS

In einer Welt, die sich früher an den Grenzen orientierte, konzentrierten sich viele Sicherheitsteams in erster Linie auf die Sicherung des Nord-Süd-Verkehrs, der in das Unternehmen hinein- und aus ihm herausführt - in der Annahme, dass das, was intern ist, ein höheres Maß an Vertrauen genießt. Es hat sich jedoch immer wieder gezeigt, dass dies nicht immer der Fall ist.

Angesichts der zunehmend durchlässigen Grenzen, die es zu verteidigen gilt, richtet sich die Aufmerksamkeit auf den internen Ost-West-Verkehr. Organisationen, die in stark regulierten Branchen tätig sind, können dies sogar vorschreiben. Istio unterstützt diese Bemühungen, indem es die Maschine-zu-Maschine-Kommunikation zwischen Services in verschiedenen Kubernetes-Clustern sichert.

Dies geschieht über Mutual TLS (mTLS), das eine transparente, bidirektionale Verschlüsselung von Dienst zu Dienst mit Public-Key-Zertifikaten bietet. Diese Zertifikate fungieren als Maschinenidentitäten und bieten eine gegenseitige Authentifizierung, dass die beiden Parteien, die sich verbinden, die sind, für die sie sich ausgeben, damit sie sicher miteinander kommunizieren können.

Auf den ersten Blick ist dies eine großartige Funktion für Unternehmen, die Maschinenidentitäten in der Cloud verwalten, da Istio automatisch eine eindeutige Identität für jeden Container, Cluster und Microservice generiert. Dies hat die Aufmerksamkeit vieler Entwickler geweckt, da es sie von der Verwaltung der Maschinenidentität entlastet. Bei näherem Hinsehen gibt es jedoch einige Bedenken.

Die Herausforderung von selbstsignierten Maschinenidentitäten

Maschinenidentitäten als Authentifizierungssystem erfordern ein gewisses Maß an Kontrolle, um effektiv zu sein. Istio unterstützt jedoch nur selbstsignierte Maschinenidentitäten, die sofort einsatzbereit sind. Diese selbstsignierten Maschinenidentitäten sparen zwar Zeit und Geld für Entwickler, setzen Unternehmen aber auch einem Sicherheitsrisiko aus. Das liegt daran, dass sie die Kontrolle aufgeben und die Sichtbarkeit verringern - beides wird von Sicherheitsteams gefordert -, da selbstsignierte Maschinenidentitäten außerhalb der bestehenden Infrastruktur für die Verwaltung von Maschinenidentitäten in Unternehmen liegen.

Selbstsignierte Zertifikate werden nicht von einer öffentlich vertrauenswürdigen Zertifizierungsstelle signiert. Darüber hinaus können sie nicht widerrufen werden und laufen nie ab. Das hört sich nach einem Vorteil an, aber wenn der private Schlüssel kompromittiert ist, könnte die Unfähigkeit, ihn zu widerrufen, Bedrohungsakteuren Tür und Tor öffnen.

Bei der Maschinenidentitätsverwaltung von Istio wissen die Sicherheitsteams auch nicht, welche Identitäten ausgestellt wurden, ob sie von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden, in welchem Kontext die Identität ausgestellt wurde oder welche Identität in welchem Cluster verwendet wird - alles entscheidende Faktoren für die Absicherung komplexer nativer Cloud-Umgebungen.

Diese Risiken werden durch die Art und Weise, wie Unternehmen ihre Kubernetes-Umgebungen verwalten, noch verschärft. Entwicklerteams gehen zunehmend von der Bereitstellung großer Cluster zu mehreren kleineren Clustern über, von denen sich vielleicht jeder auf eine einzelne Anwendung, Teameinheit oder Geschäftsregion bezieht.

Die Herausforderung bei diesem agileren Ansatz besteht darin, dass er noch mehr Komplexität und damit mehr zu verwaltende Zertifikate schafft, da diese Cluster sicher miteinander kommunizieren müssen. Es ist vielleicht nicht überraschend, dass 94 Prozent der Befragten einer Red-Hat-Umfrage im letzten Jahr zugaben, in den letzten 12 Monaten einen Kubernetes-Sicherheitsvorfall erlitten zu haben.

Geschwindigkeit vs. Sicherheit – das uralte Rätsel

Um diese Risiken zu minimieren, haben viele Istio-Unternehmenskunden damit begonnen, ihre eigenen Zertifikate unter Verwendung bewährter Zertifizierungsstellen und Infrastrukturen auszustellen. In Anbetracht der Menge und der Tatsache, dass die Lebenszyklen von Maschinenidentitäten in diesen Umgebungen nur eine Stunde betragen können, kann dies jedoch ein kostspieliger, zeitaufwändiger und schwierig zu verwaltender Prozess sein.

Es ist eine unmögliche Aufgabe, all diese Identitäten manuell zu verwalten. Unvermeidlich kann es passieren, dass sie ablaufen, ohne erneuert zu werden. Entwickler, die ihre Arbeit erleichtern wollen, können Identitäten mit einer längeren Lebensdauer ausstellen, um nicht ständig neue ausstellen zu müssen. Dies führt jedoch nur zu weiteren Problemen, da kürzere Identitäten heute in der Regel als sicherer angesehen werden.

Einige Entwickler verwenden außerdem Wildcard-Zertifikate, bei denen ein und dasselbe Zertifikat in mehreren Domänen und Clustern verwendet wird. Dies kann die Flexibilität erhöhen und die Kosten senken; doch es droht auch ein Single Point of Failure, wenn ein einzelnes Zertifikat kompromittiert wird, und es erfordert zusätzlichen Aufwand bei der Verfolgung von Erneuerungen.

Im besten Fall können diese Praktiken dazu führen, dass Entwickler nicht in der Lage sind, neue Arbeitslasten und Dienste zu Anwendungen hinzuzufügen, was die Innovation bremst. Sie können auch gegen interne Richtlinien und externe gesetzliche Anforderungen verstoßen, was bedeutet, dass Entwickler die damit verbundenen Dienste gar nicht in der Produktion einsetzen können.

Im schlimmsten Fall können schlecht verwaltete Identitäten zu Ausfällen führen, da ein Ablaufdatum scheinbar aus heiterem Himmel eintritt und ganze Anwendungen und Dienste vom Netz genommen werden. Dies führt zu Reibereien zwischen Entwicklern und Sicherheitsteams, die ständig darum kämpfen, ein Gleichgewicht zwischen Geschwindigkeit und Sicherheit sowie Kontrolle und Innovation zu finden.

Maschinenidentitäten managen

Gartner zufolge werden bis zum Jahr 2025 voraussichtlich 85 Prozent der Unternehmen weltweit containerisierte Workloads in der Produktion einsetzen. Istio ist eine zunehmend beliebte Wahl für einige Unternehmen. Aber seine mTLS-Funktionen führen ungewollt zu zusätzlichen Sicherheits- und Betriebsproblemen. Unternehmen, die das Tool nutzen, benötigen eine effektivere, automatisierte Möglichkeit, ihr eigenes Identitätsmanagement innerhalb von Kubernetes zu verwalten.

Glücklicherweise gibt es solche Lösungen, dazu zählen Angebote für das maschinelle Identitätsmanagement, die eine vollständige Verwaltung des Lebenszyklus von X.509-Zertifikaten (d. h. TLS) in Kubernetes ermöglichen. Was wäre erforderlich, um den Kunden einen Mehrwert zu bieten? Integrierte Unterstützung für eine Reihe von Anbietern von Maschinenidentitäten wie ACME und HashiCorp Vault wäre ein guter Anfang, der es Unternehmen ermöglicht, mit ihren bevorzugten PKI-Lösungen zu arbeiten.

Um dies zu ermöglichen, müssten die „Istiod“-Registrierungsstelle (RA) und die CA durch einen neuen Dienst ersetzt werden. Dieser Agent würde die RA durchführen, fein abgestufte Richtlinienkontrollen bieten und sich in den bevorzugten Emittenten des Unternehmens integrieren. Außerdem sollte er den gesamten Prozess der Identitätserstellung und des Lebenszyklusmanagements in einer robusten und zuverlässigen Lösung automatisieren. Dies spart Zeit für die Entwickler und bietet die Sicherheit und Transparenz, die Sicherheitsteams benötigen, während es gleichzeitig alle Bedenken hinsichtlich der Einhaltung von Vorschriften ausräumt.

Hilfreich wäre auch, wenn die Lösung Cloud-agonistisch wäre, so dass sie in Multi-Cloud-Umgebungen eingesetzt werden kann. Dies würde es den Entwicklern ermöglichen, einen zentralisierten und vollständig automatisierten Ansatz für die Verwaltung von Maschinenidentitäten in Cloud-Infrastrukturen zu implementieren.

Weitere Funktionen, die in diesem Zusammenhang von Nutzen sein könnten, sind eine Kontrollebene für eine clusterübergreifende Sichtbarkeit und Konfigurationskontrolle. Dies gibt Plattform- und Sicherheitsteams die Möglichkeit, den Zustand und den Status ihrer Maschinenidentitätsmanagement-Umgebung und die allgemeine Sicherheitslage zu überprüfen. Darüber hinaus lässt sich der Lebenszyklus, die Authentifizierung, die Autorisierung und die Governance aller Maschinenidentitäten in ihrer Cloud-Umgebung zu verwalten. Dies sorgt für Beobachtbarkeit, Konsistenz und Zuverlässigkeit. Das Endergebnis: Sicherheit und Konsistenz im großen Maßstab, um die Sicherheitslage zu verbessern und die Teams mit Maschinengeschwindigkeit arbeiten zu lassen.

Fazit

Service Mesh-Angebote wie Istio bieten eine dedizierte Infrastruktur zur Automatisierung und Vereinfachung von Prozessen in den Bereichen Sicherheit, Beobachtbarkeit und Traffic-Management. Das ist auf der einen Seite gut für die Teams, die mit dem wachsenden Umfang und der Komplexität ihrer Container-Umgebungen zu kämpfen haben. Aber mit einer ineffektiven, integrierten Verwaltung der Maschinenidentität können sie Sicherheits- und Compliance-Risiken schaffen, die Unternehmen in den Griff bekommen müssen.

Mit den richtigen Tools, die mit Istio zusammenarbeiten, können die Sicherheitsteams von Unternehmen eine angemessene Corporate Governance-Aufsicht ausüben, um sicherzustellen, dass Maschinenidentitäten in Übereinstimmung mit Richtlinien verwaltet werden. Und sie können dies auf eine rationalisierte, automatisierte Weise über eine Steuerungsebene tun. Dies trägt dazu bei, Cyberrisiken zu minimieren und gibt letztlich grünes Licht für die Beschleunigung der digitalen Transformation.

* Sitaram Iyer ist Senior Director Cloud Native Solutions bei Venafi.

(ID:48707838)