Si vous passez au maillage de services Istio, il y a beaucoup de choses que vous devez prendre en compte, la sécurité étant le point le plus important. Cette conversation commence généralement par la façon de gérer correctement les certificats et de contrôler l'authentification Istio mTLS pour votre déploiement de service mesh.
Dans ce blog, nous allons explorer les tenants et les aboutissants du maillage de services Istio, pourquoi il est essentiel de configurer correctement Istio mTLS et la gestion des certificats, et comment Keyfactor Command s'intègre à Istio pour garantir que chaque certificat émis dans votre maillage de services est fiable, conforme et à jour.
Vous voulez sauter le blog et passer directement à la démo ? Il vous suffit de cliquer sur le bouton "Regarder maintenant" ci-dessous.
Si vous êtes toujours avec moi, plongeons dans le vif du sujet.
Qu'est-ce que Istio Service Mesh ?
Les architectures microservices d'aujourd'hui sont incroyablement complexes. Contrairement aux applications monolithiques, où vous avez une seule application à gérer, les microservices introduisent toutes sortes de complexité.
Ces applications sont divisées en parties, appelées "services", qui interagissent les unes avec les autres. Les communications entre services sont ce qui rend les microservices possibles, mais à mesure que l'on augmente et que l'on diminue l'échelle, le défi devient : "Comment comprendre et sécuriser toutes ces interactions à l'échelle ?"
Istio est un maillage de services populaire qui, à un niveau élevé, vous permet d'abstraire la complexité de la gestion et de la sécurisation des connexions entre services. Il utilise un plan de données pour gérer le trafic entre les services et un plan de contrôle pour gérer et sécuriser le plan de données. Il comprend tout, de l'équilibrage de la charge et du comportement du trafic à l'authentification entre les services. C'est là qu'intervient Istio mutual TLS (mTLS).
Istio mTLS : avantages et inconvénients
Lorsque les entreprises commencent à se plonger dans les microservices, les pare-feu traditionnels, les équilibreurs de charge et les services de journalisation ne peuvent tout simplement pas suivre le rythme, et un maillage de services tel qu'Istio commence à prendre tout son sens.
Cependant, il existe de nombreux défis à relever pour s'assurer que la sécurité est correctement mise en œuvre. L'un des défis les plus importants consiste à configurer correctement le cryptage et l'authentification sur TLS .
Istio propose l'adresse TLS "en tant que solution complète pour l'authentification de transport, qui peut être activée sans nécessiter de modifications du code". Du point de vue de la sécurité, c'est une bonne chose. Elle fournit une authentification forte de charge de travail à charge de travail, chiffre les communications et empêche les attaques de type " man-in-the-middle ".
Par défaut, Istio utilise une autorité de certification (AC) intégrée pour générer un certificat racine auto-signé, qui est utilisé pour signer les certificats de charge de travail pour mTLS. C'est là que les problèmes commencent. Le plus souvent, l'utilisation d'une autorité de certification intégrée s'accompagne de lacunes en matière de sécurité et de visibilité.
Ce qu'il faut savoir sur les autorités de certification intégrées
Au-delà du site traditionnel PKI, un certain nombre d'AC intégrées sont désormais disponibles dans les outils DevOps et les services cloud. Pour commencer, Kubernetes, Istio et HashiCorp Vault proposent tous une AC intégrée.
Les équipes DevOps apprécient le fait que ces outils leur permettent de mettre en place une autorité de certification et de commencer à émettre des certificats rapidement. Cependant, dans de nombreux cas, cela se fait sans aucune considération pour les implications en matière de sécurité. Une fois que l'équipe PKI en a eu vent, les projets s'arrêtent souvent pendant qu'elle cherche comment obtenir la politique et la surveillance dont elle a besoin.
Pourquoi ? Parce que les équipes de PKI savent que la mise en place d'un CA ne consiste pas seulement à le faire fonctionner.
Par exemple, j'ai récemment travaillé avec une société financière du Fortune 100. Elle disposait d'un site d'entreprise très robuste, PKI , qu'elle avait passé beaucoup de temps à mettre au point. Et PKI n'est pas seulement une technologie, une infrastructure, mais aussi des choses comme une cérémonie de signature de la racine et un flux de travail de politique de CP/CPS concernant qui obtient des certificats et dans quelles circonstances ils peuvent utiliser ces certificats.
Il n'était tout simplement pas envisageable de mettre en place une autorité de certification auto-signée et de commencer à produire de gros volumes de certificats, sans l'application de la politique ou la visibilité dont ils ont besoin. Ils devaient s'assurer que tous les certificats étaient émis à partir d'une racine de confiance sécurisée ( PKI), qu'ils étaient conformes aux politiques et qu'ils étaient gérés tout au long de leur cycle de vie.
Istio mTLS : pourquoi c'est important
Alors, comment activer Istio mTLS tout en répondant aux exigences de l'entreprise PKI ?
Nous avons conçu Keyfactor Command pour qu'il s'intègre dans les flux de travail natifs d'Istio, agissant comme un plan de contrôle entre votre PKI exploité par l'entreprise et votre déploiement Istio. Au lieu d'utiliser l'autorité de certification intégrée, Istio communique directement avec Keyfactor pour émettre :
- Certificats mTLS
En utilisant le snap-in Keyfactor de l'agent Istio, vous pouvez vous assurer que lorsque les nœuds démarrent, ils peuvent obtenir des certificats de confiance acheminés en interne à partir de votre site privé PKI, d'autorités de certification publiques telles que DigiCert ou Entrust, ou même hébergés PKI en tant que service, comme le site Keyfactor PKI as-a-Service.
- Certificats Ingress/Egress
Nous pouvons également provisionner des certificats pour Ingress dans la passerelle Istio, ou quelque chose comme un contrôleur NGINX Ingress. Vous pouvez fournir des certificats à partir de votre site PKI, qu'il s'agisse d'autorités de certification publiques ou privées, et exploiter ces certificats dans les déploiements Istio et Kubernetes.
En ce qui concerne l'émission de certificats, l'intégration est simple. Le proxy Envoy demande une identité de charge de travail à l'agent Istio, qui la transmet au fournisseur Keyfactor . Une fois que Keyfactor Command valide la demande et récupère le certificat, il le renvoie automatiquement à l'agent Istio (voir ci-dessous).
Grâce à l'intégration Keyfactor-Istio, les équipes DevOps peuvent exploiter Istio sans interruption, tandis que les équipes PKI et de sécurité obtiennent ce dont elles ont besoin, notamment :
- Visibilité : Obtenez un inventaire complet des certificats émis par les autorités de certification publiques et privées, et suivez de manière centralisée les données critiques telles que les emplacements, les clés et les algorithmes, ainsi que l'expiration.
- Intelligence : Ajoutez des attributs puissants aux certificats au-delà du format X.509 standard pour les rechercher et les gérer plus efficacement (par exemple, le propriétaire de l'application, le centre de coûts, le cluster, etc.)
- Politique : Appliquer des politiques et des flux de travail cohérents en matière d'émission de certificats afin de se conformer aux exigences d'audit interne et externe.
Quelle est la prochaine étape ?
Bien que le plugin Keyfactor-Istio soit puissant pour PKI et les équipes de sécurité, chaque déploiement de microservices est différent et il ne devrait jamais y avoir qu'une seule façon de s'intégrer. Plus récemment, nous avons constaté un désir accru d'intégration directe dans Kubernetes.
Keyfactor s'intègre actuellement à Kubernetes via le serveur ACME et le cert-manager de Keyfactor . Pour en savoir plus sur cette intégration, regardez la démonstration à la demande dans Google Kubernetes Engine (GKE) ci-dessous.
