Avec Ambient Mesh, Google et Solo.io proposent un Istio sans side-cars

Découpler les couches L4 et L7

D’où la volonté de proposer Istio Ambient Mesh. « Il s’agit de proposer une nouvelle option pour qu’un seul control plane puisse piloter des applications supervisées à l’aide de side-cars et d’autres sans ce composant. Ce choix se fait au niveau du namespace », informe Denis Jannot.

Pour se passer du side-car, Solo.io et Google proposent de séparer les fonctionnalités d’Istio « en deux couches distinctes ». « L’idée, c’est de séparer les couches L4 et L7 », précise le directeur field engineering chez Solo.io.

Celles-ci sont liées au modèle OSI (Open System Interconnection) : il décrit les sept couches qu’un système informatique utilise pour communiquer à travers un réseau. La L4 est la couche de transport des données à travers des protocoles de transmission tels TCP et UDP. Dans Istio, elle sert à réaliser le routage TCP, à récupérer les logs et les métriques TCP, à déployer des tunnels mTLS et à gérer des autorisations simples.

La couche L7 correspond à celle de l’application. Dans Istio, elle est utilisée pour le routage HTTP, la répartition de charges, activer les circuits breakers, placer des limites, réaliser des injections de perturbation en sus de la gestion des autorisations avancées et de récupérer des logs, traces et métriques HTTP. Jusqu’alors, toutes ces fonctionnalités liées au data plane dépendaient du side-car.

Au lieu d’un side-car, Solo et Google proposent d’instaurer un agent partagé – nommé ztunnel (pour zero-trust tunnel) – s’exécutant sur chaque nœud d’un cluster Kubernetes. Cet agent, déployé comme un daemonset, est consacré à l’application des fonctions de la couche L4, et à la connexion et l’authentification des éléments présents au sein du maillage. « Cela permet d’indiquer quels services peuvent communiquer ensemble de manière sécurisée », résume Denis Jannot.

« La pile réseau du nœud redirige tout le trafic des charges de travail participantes via l’agent ztunnel local », précisent les responsables du projet.

Autre avantage, la gestion du chiffrement mTLS et des autres fonctionnalités de la couche L4 consomment moins de ressources RAM et CPU.

Surtout, l’agent ztunnel et les règles de gestion y afférentes peuvent être mis à jour sans affecter l’application. Oui, dans ce cas, le data plane est séparé de l’application. « Il y a même des applications qui supportaient mal les side-cars, dont Apache Kafka, qui pourront en profiter », vante Denis Jannot.

 La couche L7, elle, est configurée au niveau des namespaces via une variante du proxy Envoy, nommée Waypoint. Les proxys Waypoint sont des pods Kubernetes pouvant s’adapter automatiquement aux charges de travail, selon la documentation. Ils sont déployés par identité (nommée service account dans Kubernetes) pour éviter de recourir à un proxy L7 multitenant.

Les agents ztunnels communiquent avec un ou plusieurs proxys via Istiod. « Le control plane d’Istio configure les ztunnels du cluster afin de faire passer tout le trafic nécessitant un traitement L7 par le proxy Waypoint ».

Il aurait été plus simple de déployer un proxy Waypoint par nœud. « C’est techniquement facile, mais c’est une très mauvaise idée », prévient le directeur field engineering. « Si un proxy gère toutes les fonctionnalités L7 d’un nœud, cela veut dire qu’à chaque vulnérabilité, il y a un risque de prise de contrôle. Même s’il est robuste, la majorité des CVE signalées pour Envoy concernaient les traitements L7 ».

Autre point, un proxy par nœud entraînerait un problème de « voisins bruyants ». « Avec Envoy, nous avons la notion de filtres pour traiter les requêtes HTTP », explique Denis Jannot. « Ces filtres peuvent avoir un impact sur la latence. Si beaucoup de services utilisent le même proxy, nous allons rencontrer ce problème de “noisy neighbours” et potentiellement impacter plusieurs applications ».

« Nous ne disons pas adieu aux side-cars »

Les contributeurs principaux d’Istio avaient déjà œuvré pour stabiliser et simplifier le déploiement de ce maillage de services. Ainsi, ils avaient réuni un ensemble de composants dans le monolithe Istiod, mais n’avaient pas encore touché à Envoy.

S’il semble représenter un écart avec la philosophie originelle du projet, Ambient Mesh ne signe pourtant pas la fin des side-cars. « Nous ne disons pas adieu aux side-cars », signale le directeur field engineering. « Beaucoup de gens ne vont pas le comprendre, mais il s’agit de faire cohabiter les deux modes : side-car et ambient. Il sera possible d’avoir un seul service mesh constitué de pods avec et sans side-cars », répète-t-il.

« Beaucoup de gens ne vont pas le comprendre, mais il s’agit de faire cohabiter les deux modes : side-car et ambient ».

Cette approche duale n’est pas si surprenante au vu de l’échelle de certains déploiements d’Istio dans des grands groupes et chez les éditeurs. Idit Levine, PDG de Solo.io, évoque dans un communiqué de presse le cas de certains clients qui exécutent 30 milliards de transactions par jour sur leur service mesh existant. Pour rappel, les contributeurs cherchent à stabiliser Istio, ce qu’ils affirment avoir réussi à faire quatre ans après son lancement. La nouvelle approche pourrait être source de confusion. Solo et Google prennent donc des pincettes.

Néanmoins, la nouvelle option d’architecture semble intéresser certains clients de Solo, notamment T-Mobile. « Le principal obstacle à l’adoption du service mesh a toujours été la complexité, » avance Joe Searcy, membre du personnel technique chez T-Mobile dans un communiqué de presse. « Les coûts indirects en termes de ressources et de services liés à la gestion du service mesh au sein des grandes entreprises continuent à rendre l’adoption du service mesh difficile, même si des projets comme Istio s’efforcent de réduire la complexité », constate-t-il.

« Les possibilités qu’offre Ambient Mesh sont extrêmement intéressantes. Avec une meilleure transparence pour les applications, moins de pièces mobiles, une invocation plus simple et un énorme potentiel d’économies de ressources informatiques et d’heures d’ingénierie… tout ce que je peux dire, c’est : j’adhère ! ».

Selon Google et Solo.io, cette combinaison des modes ambient et side-car n’introduirait pas de limitations ou de problèmes de sécurité supplémentaires. De ce point de vue, Denis Jannot considère que les deux modes ont leurs avantages et leurs inconvénients. Toutefois, l’analyse de sécurité penche en la faveur du nouveau data plane.

« Les side-cars sont colocalisés avec les charges de travail qu’ils servent et, par conséquent, une vulnérabilité dans l’un compromet l’autre », écrivent les responsables du projet. « Dans le mode Ambient Mesh, même si une application est compromise, les proxys ztunnels et Waypoint peuvent toujours appliquer une politique de sécurité stricte sur le trafic de cette application ».

Outre la plus grande sensibilité aux vulnérabilités de la couche L7, les responsables indiquent que si l’agent ztunnel est partagé, sa surface d’attaque est moindre. « Au fur et à mesure que les gens comprennent mieux la posture de sécurité d’Ambient Mesh, nous sommes convaincus que ce dernier sera le mode préféré de déploiement d’Istio, tandis que les side-cars seront utilisés pour des cas d’usage spécifiques », avancent les responsables.

Une alternative au duo Envoy – eBPF

Outre la recherche d’une plus grande simplicité pour les utilisateurs, la communauté derrière Istio voit poindre une nouvelle tendance à l’horizon. Celle-ci vise à constituer un service mesh reposant sur le projet eBPF. C’est la prétention de Cilium, par ailleurs partenaire de Solo.io.

« L’agent ztunnel qui gère la couche L4 pourrait être remplacé par un équivalent en provenance d’eBPF », suppose Denis Jannot. « Cela n’est pas possible au niveau de la couche L7 : même Cilium utilise Envoy pour la gérer ».

« De plus, ztunnel fait mieux qu’eBPF en apportant le mTLS et en conservant l’identité de la source. EBPF pourrait permettre d’obtenir les mêmes fonctionnalités, mais cela reste techniquement complexe et personne ne le fait aujourd’hui », juge-t-il.

Si Solo.io promet d’automatiser certains aspects du déploiement d’Ambient Mesh, le framework n’est disponible que dans une préversion technique dans la version 2.1 de la plateforme Gloo Mesh. La distribution open source est présentée comme une mouture « expérimentale » pouvant être testée depuis des instances GKE et EKS. « Même si Ambient Mesh est déjà bien doté, il y a encore des limitations et la proposition est ouverte à contribution », suggère Denis Jannot.