Pourquoi la gestion de l'identité machine est-elle essentielle dans un déploiement de services mesh ?

L'identité machine n'est certainement pas le seul barrage au déploiement efficace d'un maillage de service mais c'est une étape importante.

Malgré les nombreuses turbulences macro-économiques, la promesse de la transformation numérique se poursuit. Lorsque les conditions commerciales sont difficiles, les projets cloud offrent des opportunités de croissance efficace, une amélioration de la productivité et une plus grande agilité. Kubernetes est d’ailleurs devenue une composante essentielle afin que les équipes de plateformes déploient de multiples clusters à travers des environnements multicloud. Pourtant, il reste nécessaire d’en améliorer la gouvernance.

C’est à ce moment-là que les maillages de service (Service Mesh) tels qu’Istio sont intéressants. Les promesses de livraison n’étant pas faciles à respecter, cela nécessitera une planification minutieuse, l’aide d’experts et l’utilisation d’outils de gestion de l’identité machine adaptés au cloud.

Présentation du maillage de service

L’utilisation de Kubernetes s’est accélérée en 2022, avec un chiffre record cette année : 96% des organisations utilisent ou évaluent la technique, contre 83% en 2020 et 78% en 2019. L’utilisation de cette fonctionnalité a augmenté et en même temps qu’elle, la façon dont les organisations déploient la technologie dans leurs projets a également évolué. Alors qu’elles établissent des clusters à travers le cloud, la nécessité d’une surveillance devient de plus en plus importante.

Les maillages de service proposent une option de plus en plus populaire – en agissant en tant que couche d’infrastructure séparée établie sur le haut des clusters de Kubernetes, ils offrent plusieurs fonctionnalités de connectivité de réseau et de sécurité pour ces clusters. Ils comprennent un TLS mutuel (mTLS) pour un chiffrage transparent de pod à pod, en utilisant des certificats TLS. À l’origine, cela permet une communication réciproque entre les charges de travail. L’ensemble du trafic qui s’écoule à travers le maillage de service, permet de l’observer de manière plus approfondie – et de mieux suivre les demandes d’un pod à l’autre et les informations relatives aux performances. Les utilisateurs bénéficient également de davantage d’options de déploiement, d’une personnalisation du trafic, et d’une coupure du circuit – par exemple, lorsque les pods ne peuvent pas communiquer.

Bien qu’il existe de multiples vendeurs de maillage de service, Istio et Linkerd sont sans doute les plus reconnus aujourd’hui. Agissant comme un cadre transparent, indifférent au langage, ils fournissent tous les avantages du maillage de service.  

Les barrages au déploiement d’Istio

Bien que ces avantages soient indéniables, il en va de même pour les défis qui accompagnent la mise en œuvre d’Istio, voire de toute architecture de maillage de services. Cela peut dissuader de nombreuses entreprises qui manquent du temps, d’argent et des compétences internes pour soutenir ces projets. L’un des défis concerne les sidecars. Chaque pod dispose d’un conteneur d’application principal et d’un conteneur « sidecar » qui contient le proxy du maillage de service – c’est l’ingrédient secret qui permet aux organisations d’exploiter tous ces avantages du maillage de service, puisque c’est là que le trafic du réseau provenant du conteneur d’application du pod est dirigé.

Toutefois, les « sidecars » ajoutent à la latence et utilisent des ressources de l’unité centrale et de la mémoire, ce qui peut représenter un casse-tête supplémentaire, à grande échelle. Istio, avec son utilisation du proxy d’open source Envoy comme sidecar, y est particulièrement sensible.  Linkerd a choisi de développer son propre sidecar proxy, plus léger, basé sur Rust, et de fournir une recherche astreignante suggérant que son impact sur la latence et son utilisation des ressources sont bien inférieures.

De grands efforts ont été faits pour faciliter le déploiement d’Istio et des maillages de service en général, mais cela reste incroyablement complexe de détecter les problèmes de connectivité et de configurer l’architecture, en particulier dans des environnements de grande taille.

Pour commencer

Kubernetes présente une courbe d’apprentissage extrêmement forte. L’ajout d’un maillage de service ne ferait que renforcer la courbe. La première exigence consiste à créer une liste d’objectifs que l’organisation espère atteindre grâce à l’utilisation d’un maillage de services et de les prioriser.  Il faut décider de ce qui sera utilisé : le mTLS primaire et les passerelles d’entrée nord-sud ou est-ouest ? Réfléchissons à la façon dont ils devraient être utilisés lorsqu’un groupe a besoin de communiquer avec un service externe. Comment le trafic sera-t-il chiffré, si cela est souhaité ? Quelles devraient-être les politiques en matière d’acheminement du trafic ?

Il conviendrait également de traiter de la gestion de l’identité machine. Chaque plan de contrôle du Maillage de Service disposera d’un composant qui traite de la gestion des certificats. Lorsque le plan de contrôle est installé, il crée une autorité du certificat racine (CA) pour chaque cluster, ce qui génère des certificats signés par cette CA. Mais le fait d’avoir un CA racine auto-signé n’est certainement pas une bonne pratique, en particulier dans des secteurs très réglementés comme des services financiers.

Des certificats auto-signés n’offrent pas la visibilité et le contrôle qu’exigent les équipes de sécurité. Ils ne sont pas signés par une CA reconnue publiquement, ils ne peuvent pas être révoqués et n’expirent jamais. Les équipes qui s’occupent sérieusement des bonnes pratiques doivent donc enquêter d’une manière automatisée, indifférente au cloud afin de gérer l’intégralité du processus d’émission de l’identité et de gestion du cycle de vie. Des outils tels que  cert-manager et Jetstack Secure aident à apporter la sécurité et la visibilité dont les entreprises ont besoin dans leurs maillages de service, tout en atténuant le risque de conformité et en libérant du temps pour les développeurs.

L’identité machine n’est certainement pas le seul barrage au déploiement efficace d’un maillage de service mais c’est une étape importante. Avec l’aide des bons professionnels et une approche minutieusement planifiée, les entreprises pourront faire des pas de géants dans leurs projets de transformation numérique.