Istio Ambient Mesh — l'avenir sans sidecar ?

De nombreuses applications modernes reposent sur une architecture de microservices distribués, où chaque microservice remplit une fonction dédiée et communique fréquemment avec les autres. Pour faire simple, imaginez des briques Lego modulaires assemblées pour former une statue, par opposition à une statue monolithique taillée dans la pierre.

Un service mesh est une couche ajoutée par-dessus ces applications (ou microservices), qui apporte des fonctionnalités telles que la gestion du trafic, l'observabilité et la sécurité, sans avoir à modifier les applications elles-mêmes.

Istio est un service mesh open source qui se superpose de façon transparente aux applications distribuées existantes. Par défaut, les services au sein d'un cluster communiquent en clair, ce qui n'est pas idéal sur le plan de la sécurité. Istio sécurise ce trafic en chiffrant ces communications via mTLS (mutual TLS). Il propose également d'autres fonctionnalités, parmi lesquelles :

• Load balancing HTTP, gRPC, WebSocket et TCP
• Contrôle granulaire du trafic
• Contrôles d'accès, limites de débit et quotas
• Service discovery
• Observabilité de bout en bout (métriques et données de télémétrie, logs et traces pour l'ensemble du trafic du cluster)

Maintenant que le rôle et les bénéfices d'un service mesh sont clairs, comparons le modèle traditionnel à sidecar d'Istio avec le nouveau modèle Ambient Mesh.

Istio repose sur 2 composants fondamentaux : un Control Plane et un Data Plane.

Le Data Plane représente les communications entre les services du mesh. Le service mesh utilise un proxy Envoy déployé aux côtés de chaque service du mesh (sous forme de sidecar) ; tout le trafic entrant et sortant transite alors par ces proxys Envoy.

Le Control Plane collecte les données issues de ces proxys, puis détermine et pilote leur configuration en réconciliant l'état actuel de l'environnement avec l'état souhaité.

src : https://istio.io/latest/docs/ops/deployment/architecture/

Limites de ce modèle :

• Résilience : tout changement, comme la mise à niveau des proxys via le control plane, impose de redémarrer chaque conteneur sidecar, ce qui peut s'avérer perturbant.
• Forte consommation de ressources : les ressources des sidecars doivent être dimensionnées pour le pire scénario d'usage, ce qui est inefficace et fait grincer des dents les responsables de la facturation.
• Rupture de trafic : en particulier avec des applications dont les implémentations HTTP ne respectent pas les standards.

Le sidecar prend en charge le traitement du trafic en Couche 4 et en Couche 7. Le hic, c'est que le traitement L7 est très consommateur en CPU et qu'il est de fait imposé à tous les services, même à ceux qui n'ont besoin que d'une simple sécurisation du transport. De plus, la majorité des Common Vulnerabilities and Exposures (CVE) critiques du proxy Envoy se situent au niveau de la couche L7 : la surface d'attaque s'élargit donc considérablement lorsque l'on impose un filtrage L7 à des services qui n'en ont aucune utilité.

Istio Ambient Mesh introduit des évolutions radicales dans l'architecture du Data Plane. Ce modèle dissocie les fonctionnalités L4 et L7, jusqu'alors indissociables avec les sidecars (logique du tout ou rien).

src : https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers

Aux sidecars succède un overlay sécurisé créé par des ztunnels (zero-trust tunnels). Ces ztunnels jouent le rôle d'agents partagés, déployés sous forme de DaemonSet, soit un agent par nœud du cluster Kubernetes.

Le ztunnel s'appuie sur un programme eBPF compilé dans le composant istio-cni pour acheminer le trafic. Cette approche offre plusieurs avantages en matière de performance et de flexibilité par rapport à un routage via iptables.

Chaque ztunnel sécurise le trafic L4 des workloads situés sur son nœud.

Pour les fonctionnalités L7, Ambient Mesh permet de déployer des waypoint proxies basés sur Envoy, appliqués au niveau du namespace, afin que les workloads de ce namespace puissent tirer parti de l'éventail complet des fonctionnalités d'Istio.

src : https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers

Ces waypoint proxies montent en charge en fonction de la demande réelle des workloads du namespace dans lequel ils opèrent. C'est nettement plus efficace et économique que de réserver des ressources aux sidecars sur la base du pire scénario d'utilisation.

Cette architecture rend l'usage du service mesh Istio intrinsèquement plus ergonomique et économique : les proxys L7 ne sont déployés que là où ils sont nécessaires, ils consomment les ressources avec plus d'efficacité et passent à l'échelle de façon plus dynamique et indépendante.

Elle assure également l'interopérabilité avec le modèle traditionnel à sidecar, ce qui vous laisse une totale liberté de choix.

Deux points liés à ce nouveau modèle de Data Plane ne seront pas traités en détail ici :

1. Les performances (en raison des sauts supplémentaires) :

Istio affirme qu'en l'absence du filtrage L7 redondant et bidirectionnel du modèle à sidecar, la dégradation de performance attendue d'Ambient Mesh liée au saut supplémentaire sera largement compensée. Un billet dédié aux performances sera publié, vraisemblablement en collaboration avec Solo.io et Google, partenaires de cette évolution. 2. La sécurité (en raison du modèle d'agent partagé) :

Pour celles et ceux que préoccupent les implications de sécurité d'un Data Plane sans sidecar, je recommande la lecture du billet Ambient Mesh Security Deep Dive.

Découvrez comment installer et utiliser Istio Ambient Mesh sur GKE

Références :

• https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/
• https://istio.io/latest/about/service-mesh/
• https://istio.io/v1.15/blog/2022/ambient-security/