In diesem Tutorial bauen Sie mit Istio 1.5 und Service Mesh Hub eine private Multi-Cluster-Service-Mesh-Lösung mit Mesh-Föderation auf. Möglich wird das durch einen Internal Load Balancer (ILB), der Istio-workloads in privaten, regionsübergreifenden Google Kubernetes Engine (GKE)-Clustern miteinander verbindet.
Einleitung
Istio 1.5 ist am 5. März erschienen und bringt mit diesem Major-Release mehrere wichtige Änderungen. Die Unterstützung für Hashicorp Vault als externe CA ist allerdings noch in Arbeit. Deshalb habe ich mich auf die Suche nach Alternativen gemacht, um die gemeinsame Root-CA sicher zu verwalten – und bin auf das Open-Source-Projekt von solo.io gestoßen: Service Mesh Hub. Service Mesh Hub vereinheitlicht die Root-Identität über mehrere Service-Mesh-Installationen hinweg. Heißt konkret: Alle Intermediate-Zertifikate werden von derselben Root-CA signiert, und die Ende-zu-Ende-mTLS-Kommunikation zwischen Clustern und Services lässt sich sauber aufbauen.
Funktionsweise
In diesem Tutorial:
bauen wir folgende Architektur auf:
Es gibt mehrere Gründe, Google Kubernetes Engine (GKE)-Cluster vom Internet abzuschotten – Sicherheit steht dabei an erster Stelle. In einem privaten Cluster haben die Nodes ausschließlich private RFC-1918-Adressen und sprechen über ein privates Netzwerk mit dem privaten Endpunkt des Masters. Damit ist jeglicher Zugriff aus dem öffentlichen Internet ausgeschlossen – ob autorisiert oder nicht.
Der TCP/UDP Internal Load Balancer hat ein eher unbekanntes Beta-Feature: Global Access. Damit können Clients aus jeder Region Ihres VPC-Netzwerks auf den internen TCP/UDP-Load-Balancer zugreifen. Ohne Global Access muss Datenverkehr von Clients innerhalb des VPC-Netzwerks in derselben Region wie der Load Balancer bleiben. In privaten Kubernetes-Clustern aktivieren Sie Global Access pro Service über folgende Annotation:
networking.gke.io/internal-load-balancer-allow-global-access:"true".
In der Beispielimplementierung annotieren wir den ingressGateway-Kubernetes-Service direkt, um einen GCP-ILB mit Global Access bereitzustellen. Sobald Global Access greift, steht die Netzwerkverbindung zwischen unseren privaten Clustern in den verschiedenen Regionen.
Geschafft! Service A (sleep.foo.cluster-1) muss nun mit Service B (httpbin.bar.cluster-2) in einem anderen Mesh kommunizieren. Wenn ein Service in einem Mesh einen Service aus einem anderen Mesh anspricht, müssen Identität und Vertrauen zwischen beiden Meshes föderiert werden. Dazu tauschen die Meshes ihre Trust-Bundles aus.
Mit Service Mesh Hub fassen Sie mehrere Meshes zu einem Objekt namens VirtualMesh zusammen. Sobald Sie diese Ressource anlegen, weisen Sie das Service Mesh an, eine gemeinsame Root-Identität über alle Cluster im Virtual Mesh hinweg aufzubauen und die Services zu föderieren.
Der Shared-Root-Prozess im Detail
Beim Anlegen der VirtualMesh-Ressource passiert Folgendes:
- Service Mesh Hub stößt den Prozess an, die Identität über eine gemeinsame Root zu vereinheitlichen.
- Service Mesh Hub setzt auf jedem Cluster einen Certificate Signing Request (CSR)-Agent ein, der ein neues Schlüssel-/Zertifikatspaar erzeugt – die Grundlage für eine Intermediate CA. Die Intermediate CA jedes Clusters wird dort vom jeweiligen Mesh genutzt.
- Anschließend entsteht ein Certificate Signing Request, abgebildet durch die VirtualMeshCertificateSigningRequest-CR.
- Service Mesh Hub signiert das Zertifikat dann mit der im VirtualMesh angegebenen Root-CA.
- Ist der Prozess abgeschlossen, müssen wir die
istiod-Control-Plane neu starten. Grund: Die Istio-Control-Plane lädt die CA für Citadel und rotiert sie nicht oft genug. In künftigen Istio-Versionen wird das verbessert.
Sobald das Vertrauen steht, beginnt Service Mesh Hub mit der Föderation der Services und legt die Service Entries automatisch für Sie an! – damit sie clusterübergreifend erreichbar sind.
In diesem Tutorial ist das Flag enforceAccessControl deaktiviert – das wird Thema eines meiner nächsten Artikel. Dort schauen wir uns an, wie Istio mit starker Identität, leistungsfähigen Policies sowie Authentication-, Authorization- und Audit-Tools (AAA) Ihre Services und Daten absichert.
Tutorial-Code
Die Schritt-für-Schritt-Anleitung zu diesem Tutorial finden Sie hier:
Referenzen
- Implementierungscode — https://github.com/palimarium/multicluster-istio-smh-private-gke
- GCP — Private GKE-Cluster — https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters
- GCP — TCP/UDP Internal Load Balancer — https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
- Istio – Beispiel-Service konfigurieren — https://istio.io/docs/setup/install/multicluster/gateways/#configure-the-example-services
- Service Mesh Hub — Konzepte — https://docs.solo.io/service-mesh-hub/latest/concepts/
In diesem Tutorial habe ich gezeigt, wie unkompliziert sich eine Service-Mesh-Lösung mit Intra-Mesh-Kommunikation aufsetzen lässt. Die Kommunikation zwischen Services läuft intern über sicheren mTLS-Datenverkehr – ohne das Global Network von Google Cloud zu verlassen.