Wenn Sie auf Istio Service Mesh umsteigen, müssen Sie eine Reihe von Dingen beachten - allen voran die Sicherheit. Diese Diskussion beginnt in der Regel mit der Frage, wie Sie Zertifikate richtig verwalten und die Istio mTLS-Authentifizierung für Ihre Service-Mesh-Bereitstellung steuern.
In diesem Blog erfahren Sie alles über Istio Service Mesh, warum es wichtig ist, Istio mTLS und das Zertifikatsmanagement richtig zu konfigurieren, und wie Keyfactor Command in Istio integriert werden kann, um sicherzustellen, dass jedes Zertifikat, das in Ihrem Service Mesh ausgestellt wird, vertrauenswürdig, konform und auf dem neuesten Stand ist.
Sie möchten den Blog überspringen und direkt zur Demo kommen? Klicken Sie einfach unten auf die Schaltfläche "Jetzt ansehen".
Wenn Sie noch dabei sind, lassen Sie uns eintauchen.
Was ist Istio Service Mesh?
Die heutigen Microservices-Architekturen sind unglaublich komplex. Im Gegensatz zu monolithischen Anwendungen, bei denen Sie nur eine einzige Anwendung zu verwalten haben, bringen Microservices alle Arten von Komplexität mit sich.
Diese Anwendungen sind in Teile unterteilt, die als "Dienste" bezeichnet werden und miteinander interagieren. Die Kommunikation zwischen den Diensten macht Microservices erst möglich, aber mit zunehmender Skalierung stellt sich die Frage: "Wie können wir all diese Interaktionen im großen Maßstab verstehen und sichern?"
Istio ist ein beliebtes Service-Mesh, das es Ihnen auf hohem Niveau ermöglicht, die Komplexität der Verwaltung und Sicherung von Service-to-Service-Verbindungen zu abstrahieren. Es verwendet eine Datenebene zur Abwicklung des Datenverkehrs zwischen den Diensten und eine Steuerebene zur Verwaltung und Sicherung der Datenebene. Sie umfasst alles vom Lastausgleich über das Verkehrsverhalten bis hin zur Authentifizierung zwischen den Diensten. Und hier kommt Istio mutual TLS (mTLS) ins Spiel.
Istio mTLS: Vor- und Nachteile
Wenn Unternehmen beginnen, tief in Microservices einzutauchen, können herkömmliche Firewalls, Load Balancer und Protokollierungsdienste einfach nicht mehr mithalten, und ein Service Mesh wie Istio beginnt, mehr Sinn zu machen.
Es gibt jedoch viele Herausforderungen, um sicherzustellen, dass Sie die Sicherheit richtig implementieren. Eine der größten Herausforderungen ist die richtige Konfiguration der TLS Verschlüsselung und Authentifizierung.
Istio bietet mutual TLS "als eine Full-Stack-Lösung für die Transport-Authentifizierung, die ohne Code-Änderungen aktiviert werden kann." Vom Standpunkt der Sicherheit aus ist dies eine gute Sache. Es bietet eine starke Workload-to-Workload-Authentifizierung, verschlüsselt die Kommunikation und verhindert Man-in-the-Middle-Angriffe.
Standardmäßig verwendet Istio eine integrierte Zertifizierungsstelle (CA), um ein selbstsigniertes Stammzertifikat zu erzeugen, das zum Signieren von Workload-Zertifikaten für mTLS verwendet wird. Genau hier beginnen die Probleme. In den meisten Fällen ist die Verwendung einer eingebauten CA mit Sicherheits- und Sichtbarkeitsmängeln verbunden.
Die Sache mit den eingebauten CAs
Neben der traditionellen PKI gibt es inzwischen eine Reihe von eingebetteten CAs in DevOps-Tools und Cloud-Diensten. Zunächst einmal bieten Kubernetes, Istio und HashiCorp Vault alle eine integrierte CA.
DevOps-Teams sind begeistert, dass sie mit diesen Tools schnell eine Zertifizierungsstelle einrichten und Zertifikate ausstellen können. In vielen Fällen geschieht dies jedoch ohne Rücksicht auf die damit verbundenen Sicherheitsaspekte. Sobald das PKI-Team Wind davon bekommt, kommen die Projekte oft zum Stillstand, während sie herausfinden, wie sie die erforderlichen Richtlinien und die Aufsicht erhalten können.
Warum? Weil PKI-Teams wissen, dass es bei der Einrichtung einer CA nicht nur darum geht, sie "zum Laufen zu bringen".
Ich habe zum Beispiel kürzlich mit einem Fortune-100-Finanzunternehmen zusammengearbeitet. Das Unternehmen verfügte über eine sehr robuste, unternehmenstaugliche PKI, in die es viel Zeit investiert hat, um sie zu optimieren. Und PKI ist nicht nur Technologie, nicht nur Infrastruktur, sondern auch Dinge wie eine Root-Signierungszeremonie und ein CP/CPS-Richtlinien-Workflow, bei dem es darum geht, wer Zertifikate erhält und unter welchen Umständen er diese Zertifikate verwenden darf.
Es war keine Option, einfach eine selbstsignierte Zertifizierungsstelle einzurichten und große Mengen an Zertifikaten auszustellen, ohne die erforderliche Durchsetzung von Richtlinien oder Transparenz. Es musste sichergestellt werden, dass alle Zertifikate von einer sicheren Root of Trust (sicherheitsbetriebene PKI) ausgestellt werden, mit den Richtlinien übereinstimmen und während ihres gesamten Lebenszyklus verwaltet werden.
Istio mTLS: Warum es wichtig ist
Wie können Sie also Istio mTLS aktivieren und gleichzeitig die PKI-Anforderungen des Unternehmens erfüllen?
Wir haben Keyfactor Command so entwickelt, dass es sich in Istio-native Workflows einfügt und als Kontrollebene zwischen Ihrer unternehmenseigenen PKI und Ihrer Istio-Bereitstellung fungiert. Anstatt die integrierte CA zu verwenden, kommuniziert Istio direkt mit Keyfactor , um die Zertifikate auszustellen:
- mTLS-Zertifikate
Mit dem Snap-In Keyfactor für den Istio-Agenten können Sie sicherstellen, dass die Knoten beim Hochfahren vertrauenswürdige Zertifikate erhalten, die intern von Ihrer privaten PKI, von öffentlichen CAs wie DigiCert oder Entrust oder sogar von einer gehosteten PKI als Service, wie Keyfactor PKI as-a-Service, stammen.
- Ingress/Egress-Zertifikate
Wir können auch Zertifikate für den Ingress im Istio-Gateway oder in einem NGINX Ingress Controller bereitstellen. Sie können Zertifikate von Ihrer PKI bereitstellen, unabhängig davon, ob es sich um öffentliche oder private CAs handelt, und diese Zertifikate in Istio- und Kubernetes-Bereitstellungen nutzen.
Was die Ausstellung von Zertifikaten betrifft, ist die Integration einfach. Der Envoy-Proxy fordert vom Istio-Agenten eine Workload-Identität an, die stattdessen an den Keyfactor Provider weitergeleitet wird. Sobald Keyfactor Command die Anforderung validiert und das Zertifikat abgerufen hat, wird es automatisch an den Istio-Agenten zurückgeschickt (siehe unten).
Mit der Keyfactor-Istio-Integration können DevOps-Teams Istio ohne Unterbrechung nutzen, während PKI- und Sicherheitsteams alles bekommen, was sie brauchen, einschließlich:
- Sichtbarkeit: Erhalten Sie ein vollständiges Inventar von Zertifikaten, die über öffentliche und private CAs ausgestellt wurden, und verfolgen Sie zentral wichtige Daten wie Standorte, Schlüssel und Algorithmen sowie deren Ablauf.
- Intelligenz: Fügen Sie den Zertifikaten leistungsfähige Attribute hinzu, die über das standardmäßige X.509-Format hinausgehen, um sie effektiver zu suchen und zu verwalten (z. B. Eigentümer der Anwendung, Kostenstelle, Cluster usw.).
- Richtlinien: Setzen Sie einheitliche Richtlinien und Arbeitsabläufe für die Ausstellung von Zertifikaten durch, um die Anforderungen interner und externer Prüfungen zu erfüllen.
Was kommt als Nächstes?
Während das Keyfactor-Istio-Plugin für PKI- und Sicherheitsteams sehr leistungsfähig ist, ist jede Microservices-Bereitstellung anders, und es sollte nie nur einen Weg zur Integration geben. In letzter Zeit ist der Wunsch nach einer direkten Integration in Kubernetes gestiegen.
Keyfactor ist derzeit mit Kubernetes über den Keyfactor ACME-Server und den Cert-Manager integriert. Um mehr über diese Integration zu erfahren, sehen Sie sich die On-Demand-Demo in Google Kubernetes Engine (GKE) unten an.
