Machine Identity Management als Schlüssel Sichere Bereitstellung eines Service Mesh

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

Service-Mesh-Technologien helfen dabei, komplexe Kubernetes-Umgebungen effizienter zu steuern. Doch eine entsprechende Infrastrukturschicht erfordert ein gewisses Maß an Vorbereitung, damit es später nicht zu Performance- und Sicherheitsproblemen kommt.

Trotz des makroökonomischen Gegenwinds bleibt das Potenzial der digitalen Transformation ungebrochen. Tatsächlich bieten Cloud-Projekte in Zeiten schwieriger wirtschaftlicher Bedingungen dringend benötigte Möglichkeiten für effizientes Wachstum, Produktivitätssteigerungen und größere Agilität. Kubernetes hat sich als Schlüsselkomponente dieser Initiativen herausgestellt, da Cloud-Plattform-Teams mehrere Cluster in Multi-Cloud-Umgebungen einsetzen.

Doch die daraus resultierende Komplexität hat den Bedarf an einer verbesserten Governance erhöht. Hier kommen Service-Meshes wie Istio zum Tragen. Aber es ist nicht einfach, dieses Versprechen zu erfüllen. Es erfordert eine sorgfältige Planung, fachkundige Anleitung und den Einsatz von Cloud-agnostischen Tools für die Verwaltung von Maschinenidentitäten.

Vorstellung von Service Mesh

Die Nutzung von Kubernetes hat im Jahr 2022 noch zugenommen. Daten aus diesem Jahr zeigen, dass eine Rekordzahl von 96 Prozent der Unternehmen die Technologie entweder nutzt oder evaluiert, gegenüber 83 Prozent im Jahr 2020 und 78 Prozent im Jahr 2019. Aber auch die Art und Weise, wie Unternehmen die Technologie in Projekten einsetzen, hat sich weiterentwickelt.

Mit dem Aufbau von Clustern über verschiedene Clouds hinweg wird die Notwendigkeit der Überwachung jedoch immer akuter. Service-Meshes sind eine immer häufiger genutzte Option. Sie fungieren als separate Infrastrukturebene über Kubernetes-Clustern und bieten mehrere Netzwerkkonnektivitäts- und sicherheitsbezogene Funktionen für diese Cluster.

Dazu gehört mutual TLS (mTLS) für eine transparente Verschlüsselung von Service zu Service mit TLS-Zertifikaten. Dies ermöglicht es, dass die gesamte Kommunikation zwischen Workloads miteinander kommunizieren kann, ohne dass es zu Problemen kommt.

Da der gesamte Datenverkehr durch das Service Mesh fließt, ist eine genauere Beobachtung möglich – einschließlich der Rückverfolgbarkeit von Pod-zu-Pod-Anfragen und Leistungseinblicken. Die Benutzer profitieren außerdem von mehr Bereitstellungsoptionen, der Anpassung des Datenverkehrs und der Unterbrechung von Verbindungen, z. B. in Situationen, in denen Pods nicht miteinander kommunizieren können.

Es gibt zwar mehrere Service-Mesh-Anbieter, aber Istio und Linkerd sind heute vielleicht die bekanntesten. Als transparentes, sprachunabhängiges Framework bieten sie alle Service-Mesh-Vorteile wie einheitliche Beobachtung, Traffic-Management und richtliniengesteuerte Sicherheit – und erledigen damit eine Aufgabe, für die andernfalls mehrere Einzellösungen erforderlich wären.

Hindernisse bei der Implementierung von Istio

Während diese Vorteile unbestreitbar sind, gibt es auch die Herausforderungen, die mit der Implementierung von Istio oder jeder anderen Service-Mesh-Architektur einhergehen. Dies kann viele Unternehmen abschrecken, denen die Zeit, das Geld und die internen Fähigkeiten zur Unterstützung solcher Projekte fehlen.

Eine Schwierigkeit liegt in den Sidecars: Jeder Pod hat einen Hauptanwendungscontainer und einen Sidecar-Container, der den Service-Mesh-Proxy enthält – das ist die geheime Zutat, die es Organisationen ermöglicht, alle Service-Mesh-Vorteile zu nutzen, da der Netzwerkverkehr vom Anwendungscontainer des Pods dorthin geleitet wird.

Sidecars verursachen jedoch zusätzliche Latenzzeiten und beanspruchen CPU- und Speicherressourcen, was im großen Maßstab ein großes Problem darstellen kann. Selbst wenn jedes Sidecar nur fünf MB Arbeitsspeicher und 0,1 CPU beansprucht, würde dies, multipliziert mit 100.000 Pods, einen enormen Ressourcenverbrauch bedeuten. Istio, das den Open-Source-Proxy Envoy als Sidecar verwendet, ist dafür besonders anfällig.

Linkerd hat sich für die Entwicklung eines eigenen, leichteren, auf Rust basierenden Proxy-Sidecars entschieden und überzeugende Untersuchungen vorgelegt, die zeigen, dass die Auswirkungen auf die Latenzzeit und der Ressourcenverbrauch deutlich geringer sind. Als stillschweigendes Eingeständnis der Einschränkungen ihres Sidecar-Proxy-Ansatzes hat Istio die Vorschau von „Ambient Mesh“ angekündigt, dass einen knotenbasierten Proxy bereitstellt, der einige der zuvor von Envoy bereitgestellten Funktionen übernimmt.

Es wurden große Fortschritte gemacht, um die Bereitstellung von Istio und Service-Meshes im Allgemeinen zu vereinfachen, aber es ist immer noch unglaublich komplex, Verbindungsprobleme zu beheben und die Architektur zu konfigurieren, insbesondere in großen Umgebungen. Es gibt auch unbeabsichtigte betriebliche Probleme, die durch mTLS verursacht werden. Obwohl es mit HTTP-Verkehr gut funktioniert, wird mTLS bei TCP-Traffic problematischer - zum Beispiel, wenn ein Pod mit einer Datenbank kommunizieren muss.

Einstieg leicht gemacht, aber die Vorbereitung ist wichtig

Die Wahrheit ist, dass Kubernetes für den Nutzer mit einer enorm steilen Lernkurve einhergeht. Fügt man ein Service-Mesh hinzu, wird die Kurve nur noch steiler. Als Erstes muss eine Liste der Ziele erstellt werden, die das Unternehmen mit einem Service-Mesh erreichen möchte, und es müssen Prioritäten gesetzt werden.

Die Cloud-Plattform-Teams müssen zunächst entscheiden, wofür es verwendet werden soll: hauptsächlich mTLS und Nord-Süd- oder Ost-West-Eingangsgateways? Darüber hinaus müssen sie sich überlegen, wie es benutzt werden soll, wenn ein Pod mit einem externen Dienst kommunizieren muss – z. B. mit einer Datenbank, die sich nicht im selben Cluster befindet. Wie wird der Datenverkehr verschlüsselt, falls gewünscht? Wie sollen die Richtlinien für das Routing des Datenverkehrs aussehen?

Auch die Verwaltung der Maschinenidentität sollte berücksichtigt werden. Jede Service-Mesh-Kontrollebene verfügt über eine Komponente, die sich mit der Zertifikatsverwaltung befasst. Bei der Installation der Steuerebene wird eine Stammzertifizierungsstelle (CA) für jeden Cluster erstellt, die von dieser CA signierte Zertifikate generiert.

Eine selbstsignierte Stammzertifizierungsstelle ist jedoch sicherlich nicht die beste Praxis, insbesondere in stark regulierten Sektoren wie Finanzdienstleistungen. Für Unternehmen, die mehrere Servicemeshes (und selbstsignierte Stammzertifizierungsstellen) in Betrieb haben, vervielfacht sich das Problem. Unternehmen müssen auch bedenken, dass Pods eine relativ kurze Lebensdauer haben und jeder einzelne sein eigenes Zertifikat benötigt.

Selbstsignierte Zertifikate bieten nicht die Sichtbarkeit und Kontrolle, die Sicherheitsteams benötigen. Sie werden nicht von einer öffentlich vertrauenswürdigen Zertifizierungsstelle unterzeichnet, können nicht widerrufen werden und laufen nie ab. All dies sind Warnsignale für das Thema Sicherheit.

Teams, die es mit Best Practices in Sachen Sicherheit ernst meinen, müssen daher nach einer Cloud-unabhängigen, automatisierten Methode suchen, um den gesamten Prozess der Identitätsausstellung und des Lebenszyklusmanagements zu verwalten – unter Verwendung einer Kontrollebene für clusterübergreifende Transparenz und Konfiguration. Tools wie cert-manager und Jetstack Secure helfen dabei, die Sicherheit und Transparenz zu gewährleisten, die Unternehmen in ihren Service Meshes benötigen, und gleichzeitig das Compliance-Risiko zu minimieren und Entwicklerzeit freizusetzen.

Fazit

Die maschinelle Identität ist bei Weitem nicht das einzige Hindernis auf dem Weg zu einer effektiven Service-Mesh-Implementierung, aber sie ist ein wichtiger Schritt. Mit der richtigen professionellen Anleitung und einem sorgfältig geplanten Ansatz können Unternehmen bei ihren digitalen Transformationsprojekten große Schritte machen.

* Steve Judd ist Solutions Architect bei Venafi.

(ID:49032464)