Ce tutoriel vous montre comment déployer un service mesh multicluster privé avec Istio 1.5 et Service Mesh Hub pour la fédération de mesh. La solution s'appuie sur un Internal Load Balancer (ILB) pour relier des workloads Istio exécutés dans des clusters Private Google Kubernetes Engine (GKE) multi-régions.
Introduction
Istio 1.5 est sorti le 5 mars et cette version majeure apporte plusieurs changements importants. La prise en charge de Hashicorp Vault comme CA externe est toutefois toujours en cours. J'ai donc cherché d'autres options pour gérer la racine commune (root CA) de manière sécurisée. C'est ainsi que j'ai découvert le projet open source de solo.io, Service Mesh Hub. Service Mesh Hub permet d'unifier l'identité racine entre plusieurs installations de service mesh. Concrètement, tous les certificats intermédiaires sont signés par la même Root CA, ce qui garantit un mTLS de bout en bout correctement établi entre clusters et services.
Comment ça fonctionne
Dans ce tutoriel :
nous allons construire l'architecture suivante :
Plusieurs raisons justifient l'isolation de vos clusters Google Kubernetes Engine (GKE) vis-à-vis d'Internet, la principale étant la sécurité. Dans un cluster privé, les nœuds ne disposent que d'adresses privées RFC 1918 et communiquent avec l'endpoint privé du master via un réseau privé. Tout accès depuis Internet, autorisé ou non, est ainsi bloqué.
Le load balancer interne TCP/UDP propose une fonctionnalité bêta moins connue : Global Access. Elle permet aux clients de n'importe quelle région de votre réseau VPC d'accéder au load balancer interne TCP/UDP. Sans Global Access, le trafic provenant des clients de votre VPC doit rester dans la même région que le load balancer. Dans vos clusters Kubernetes privés, Global Access s'active service par service via l'annotation suivante :
networking.gke.io/internal-load-balancer-allow-global-access:"true".
Dans l'exemple d'implémentation, nous annoterons directement le Service Kubernetes ingressGateway pour provisionner un ILB GCP avec Global Access. Une fois Global Access appliqué, la connectivité réseau est en place entre nos clusters privés répartis dans différentes régions.
Et ça fonctionne ! Le service A (sleep.foo.cluster-1) doit communiquer avec le service B (httpbin.bar.cluster-2) situé dans un autre mesh. Lorsqu'un service d'un mesh a besoin d'un service d'un autre, il faut fédérer l'identité et la confiance entre les deux meshes, ce qui passe par l'échange du trust bundle entre eux.
Service Mesh Hub permet de regrouper plusieurs meshes au sein d'un objet appelé VirtualMesh. La création de cette ressource indique au Service Mesh d'établir une identité racine partagée entre les clusters du Virtual Mesh, et de fédérer les services.
Comprendre le processus de racine partagée
Lors de la création de la ressource VirtualMesh :
- Service Mesh Hub lance le processus d'unification de l'identité autour d'une racine partagée.
- Service Mesh Hub utilise un agent Certificate Signing Request (CSR) sur chacun des clusters pour générer une nouvelle paire clé/certificat qui constituera une CA intermédiaire. La CA intermédiaire propre à chaque cluster sera utilisée par le mesh local.
- Il crée ensuite une Certificate Signing Request, représentée par la CR VirtualMeshCertificateSigningRequest.
- Service Mesh Hub signe alors le certificat avec la Root CA spécifiée dans le VirtualMesh.
- Une fois cette étape terminée, il faut redémarrer le control plane
istiod. Le control plane Istio récupère en effet la CA pour Citadel sans la faire tourner assez fréquemment. Ce point sera amélioré dans les prochaines versions d'Istio.
Une fois la confiance établie, Service Mesh Hub fédère les services en générant automatiquement les service entries pour vous, afin qu'ils soient accessibles d'un cluster à l'autre.
Pour ce tutoriel, le flag enforceAccessControl est désactivé : il fera l'objet d'un prochain article. Nous y verrons comment Istio fournit des fonctionnalités de sécurité offrant une identité forte, des politiques robustes ainsi que des outils d'authentification, d'autorisation et d'audit (AAA) pour protéger vos services et vos données.
Code du tutoriel
Les instructions pas à pas de ce tutoriel sont disponibles ici :
Références
- Code d'implémentation — https://github.com/palimarium/multicluster-istio-smh-private-gke
- GCP — Clusters GKE privés — https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters
- GCP — Load balancer interne TCP/UDP — https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
- Istio — Configurer le service d'exemple — https://istio.io/docs/setup/install/multicluster/gateways/#configure-the-example-services
- Service Mesh Hub — Concepts — https://docs.solo.io/service-mesh-hub/latest/concepts/
Ce tutoriel illustre la simplicité avec laquelle on peut mettre en place une solution de service mesh avec communication intra-mesh. La communication entre services s'effectue en interne via un trafic mTLS sécurisé, sans jamais quitter le Global Network de Google Cloud.