Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Pourquoi les entreprises ne devraient pas se fier au mTLS d’Istio ?

novembre 2022 par Sitaram Iyer, Senior Director of Cloud Native Solutions, chez Venafi

Avec une architecture plus légère et portable que les machines virtuelles (MV), les conteneurs réduisent le système d’exploitation et fournissent un package de logiciel qui contient tout ce qu’il faut pour fonctionner dans n’importe quel environnement.

Ce boom de l’utilisation de conteneurs a créé la nécessité d’une plate-forme d’orchestration permettant de gérer ces environnements. Kubernetes est devenu le standard de facto dans l’industrie permettant de s’assurer que les conteneurs fonctionnent conformément aux spécifications et qu’ils peuvent évoluer. En automatisant des environnements conteneurisés, Kubernetes donne naissance à un environnement dynamique, multicloud, open source multiple, qui est également modulable, rentable et productif – le paradis des développeurs. Toutefois, au fur et à mesure que Kubernetes prend de la maturité, le besoin de contrôle et de gouvernance devient de plus en plus important. Et c’est là qu’apparaît Istio.

Istio devient l’outil de choix pour fournir une observabilité, une agilité opérationnelle et une sécurité conforme à la politique uniformes à travers les environnements cloud-native Kubernetes, qui grandissent chaque jour, à la fois en termes de taille et de complexité. Kubernetes s’est développée, au sein de sociétés qui déploient maintenant de multiples clusters, et Istio fournit une couche d’abstraction indispensable pour gérer la gouvernance. Pour assurer l’intégrité de ces environnements, le trafic entre les conteneurs doit être sûr avec un système d’identité fort.

Pourquoi avons-nous besoin d’un service mesh comme Istio ?

Istio fonctionne comme une couche de service mesh, fournissant un cadre transparent et agnostique au langage visant à fournir une observabilité, une gestion du trafic et une sécurité conforme à la politique uniformes. Il est conçu pour faciliter la vie des organisations, en effectuant un travail qui nécessiterait autrement de multiples solutions ponctuelles.
Malgré ces avantages majeurs, la mise en application d’Istio n’est pas une tâche facile. Elle peut nécessiter des qualifications internes significatives pour le paramétrer et le gérer.

Sécurisation du trafic interne d’une machine à l’autre avec le TLS mutuel

Dans un monde anciennement périmétrique, de nombreuses équipes de sécurité étaient essentiellement concentrées sur la sécurisation d’un trafic nord-sud se déplaçant en entrée et en sortie de l’entreprise – l’hypothèse étant que ce qui est interne présente un niveau de confiance élevé. Mais comme cela a été prouvé à maintes reprises, ce n’est pas toujours le cas. Avec un périmètre de plus en plus poreux à défendre, l’attention se tourne vers une surveillance du trafic est-ouest interne.

Fondamentalement, Istio soutient ces efforts en sécurisant la communication d’une machine à l’autre entre services dans différents clusters de Kubernetes. Il le fait par le biais du TLS mutuel (mTLS), qui offre un chiffrage transparent, bidirectionnel de service à service en utilisant des certificats de clé publique. Ces certificats agissent comme des identités machine, fournissant une authentification mutuelle qui certifie que les deux parties qui se connectent sont bien ce qu’elles disent être, de sorte qu’elles puissent communiquer en toute sécurité l’une avec l’autre.
À première vue, c’est une fonction extraordinaire pour les sociétés qui gèrent les identités machine dans le cloud car Istio génère automatiquement une identité unique pour chaque conteneur, cluster et micro-service. Cela a retenu l’attention de nombreux développeurs car cela les soulage de la gestion de l’identité machine. Toutefois, en y regardant de plus prêt, il y a quelques problèmes.

Le défi de l’identité machine auto-signée

Les identités machine, en tant que système d’authentification, nécessitent que le niveau de surveillance soit efficace. Toutefois, Istio ne prend en charge que les identités machine auto-signées originales. Ces dernières pourraient permettre aux développeurs de gagner du temps et de l’argent mais elles exposent également les entreprises à un risque pour la sécurité.

Vitesse contre sécurité – l’éternel dilemme

Afin d’atténuer ces risques, de nombreuses entreprises clientes d’Istio ont commencé à émettre leurs propres certificats en utilisant des AC et des infrastructures essayées et testées. Toutefois, vu leur quantité, et le fait que les cycles de vie d’une identité machine dans ces environnements peut durer à peine une heure, il peut s’agir là d’un processus coûteux, chronophage et difficile à gérer.

Il est impossible de garder une trace de toutes ces identités manuellement. Inévitablement, elles peuvent expirer sans être renouvelées. Les développeurs qui cherchent à alléger leur charge de travail pourraient émettre des identités ayant une durée de vie plus longue afin d’éviter de devoir en émettre de nouvelles. Toutefois, cela ne fait qu’ajouter des problèmes, car des identités plus courtes sont habituellement reconnues comme plus sûres aujourd’hui.

Une meilleure façon de gérer l’identité machine

Istio est un choix de plus en plus populaire pour certaines entreprises. Mais ses capacités en matière de mTLS introduisent involontairement des risques opérationnels et de sécurité supplémentaires. Les entreprises qui utilisent l’outil ont besoin d’une façon plus efficace, automatisée de traiter leur propre gestion de l’identité machine au sein de Kubernetes.
Heureusement, ces solutions existent. Considérons les offres de gestion d’identité machine qui fournissent une gestion du cycle de vie complète du certificat X.509 (à savoir, TLS) dans Kubernetes. De quoi auraient-elles besoin pour offrir une valeur ajoutée aux clients ? Un support intégré avec une gamme d’émetteurs d’identité machine comme ACME et HashiCorp Vault serait un bon début, permettant aux organisations de travailler avec leurs solutions PKI préférées. Pour cela, il serait nécessaire de remplacer l’autorité d’enregistrement (AR) « Istiod » et l’AC par un nouveau service. Cet agent exercerait l’AR, il organiserait des contrôles de politiques affinés, et s’intégrerait à l’émetteur préféré de l’entreprise.

L’innovation encouragée par la gestion de l’identité machine

Les offres de service mesh comme Istio proposent une infrastructure dédiée pour automatiser et simplifier des processus en tenant compte de la sécurité, de l’observabilité, et de la gestion du trafic. C’est une nouvelle fantastique pour les équipes dans les entreprises qui luttent avec le volume et la complexité croissants de leurs environnements conteneurisés. Mais une gestion de l’identité machine intégrée inefficace est susceptible de créer des risques pour la sécurité et la conformité que les entreprises devront alors gérer.
En trouvant les bons outils à utiliser avec Istio, les équipes sécurité de l’entreprise peuvent surveiller la gouvernance de la société afin de s’assurer que les identités machine sont gérées conformément à la politique. Et elles peuvent le faire d’une manière rationalisée, automatisée par le biais d’un plan de contrôle. Cela permettra de minimiser les cyber-risques, tout en donnant le feu vert à l’accélération de la transformation numérique.


Voir les articles précédents

    

Voir les articles suivants