Le protocole TLS standard assure une authentification unidirectionnelle : le client vérifie le certificat du serveur, mais le serveur ne vérifie pas celui du client. Le protocole Mutual TLS (mTLS) comble cette lacune en exigeant que les deux parties présentent leurs certificats et se valident mutuellement avant tout échange de données. Cette approche fait du mTLS la pierre angulaire des communications service-à-service dans une architecture zero trust.
Alibaba Cloud Service Mesh (ASM) applique le mTLS aux trois étapes du trafic dans un environnement Kubernetes, sans nécessiter de modification du code applicatif. Vous pouvez également exploiter les certificats fournis par le mTLS à chaque étape pour mettre en œuvre des contrôles d'accès. De plus, ASM gère automatiquement l'émission et la rotation des certificats, ce qui vous dispense de toute manipulation manuelle.
Étapes du trafic et sécurisation par ASM
Le trafic de bout en bout dans un environnement Kubernetes traverse trois étapes distinctes. ASM sécurise chacune d'elles selon des mécanismes spécifiques :
| Étape | Direction | Mécanisme de sécurisation par ASM |
|---|---|---|
| Ingress | Des clients externes vers les services du cluster | Les clients externes accèdent aux services internes via la passerelle ingress d'ASM. Configurez le mTLS et restreignez l'accès à des certificats clients spécifiques. |
| Est-Ouest | Entre les charges de travail au sein du cluster | Les proxys sidecar mettent automatiquement à niveau les connexions vers le mTLS. Aucune modification applicative ni configuration supplémentaire n'est requise. |
| Egress | Des charges de travail du cluster vers les services externes | La passerelle egress d'ASM intercepte les requêtes en texte clair émises par les charges de travail et les convertit en mTLS avant de les transférer au service externe. |
Pourquoi utiliser ASM pour le mTLS
| Avantage | Description |
|---|---|
| Séparation des responsabilités | Les applications se concentrent sur la logique métier tandis qu'ASM gère l'authentification et le chiffrement au niveau de l'infrastructure. Cela accélère les cycles de développement. |
| Gestion automatisée des certificats | ASM émet des certificats basés sur le compte de service Kubernetes (ServiceAccount) de chaque charge de travail et assure leur rotation automatique. Aucune opération manuelle sur les certificats n'est nécessaire. |
| Adoption non intrusive | Les applications existantes ne nécessitent aucune modification de code. L'injection du proxy sidecar et la configuration de la passerelle s'effectuent au niveau de l'infrastructure. |
Sécuriser le trafic ingress avec le mTLS
Les clients externes atteignent les services internes du cluster via la passerelle ingress d'ASM. Pour imposer le mTLS au niveau de l'ingress :
Configurez la passerelle ingress d'ASM pour exiger des certificats clients.
Restreignez l'accès à des clients spécifiques en validant les attributs de leurs certificats.
Pour obtenir des instructions détaillées, consultez la rubrique Configurer un service mTLS sur la passerelle ingress d'ASM et restreindre l'accès à des clients spécifiques.
Sécuriser le trafic est-ouest avec le mTLS
Le mTLS est-ouest est une fonctionnalité native d'ASM. Une fois que vous avez injecté des proxys sidecar des deux côtés d'une connexion, le trafic entre ces composants est automatiquement mis à niveau vers le mTLS, sans configuration supplémentaire.
Pour injecter des proxys sidecar, reportez-vous à la rubrique Installer un proxy sidecar.
Éléments couverts automatiquement
Trafic Pod-à-Pod : La communication entre deux Pods disposant de proxys sidecar injectés utilise automatiquement le mTLS.
Trafic passerelle-vers-sidecar : La passerelle ingress, la passerelle egress et les proxys sidecar d'ASM se connectent tous au plan de contrôle d'ASM. Les communications entre ces composants utilisent également le mTLS.
Cycle de vie des certificats
Les certificats destinés au mTLS est-ouest sont émis sur la base de l'identité du compte de service (ServiceAccount) de chaque charge de travail. Le plan de contrôle d'ASM gère à la fois l'émission et la rotation périodique, ce qui élimine toute nécessité de gestion manuelle des certificats.
Migration vers un mTLS strict
ASM prend en charge une migration progressive du texte clair vers le mTLS complet grâce aux politiques d'authentification par identité de pair :
**Pendant la migration, définissez le mode d'authentification par identité de pair sur
PERMISSIVE**. Dans ce mode, les charges de travail acceptent à la fois le trafic en texte clair et le trafic mTLS. Cela permet aux services non intégrés au maillage de continuer à communiquer pendant la transition.**Après la migration, basculez le mode d'authentification par identité de pair sur
STRICT**. Dans ce mode, les charges de travail n'acceptent que le trafic mTLS, garantissant ainsi un chiffrement complet de toutes les communications est-ouest.
Sécuriser le trafic egress avec le mTLS
Lorsqu'une charge de travail interne appelle un service externe nécessitant le mTLS, l'application peut continuer à envoyer des requêtes en texte clair. La passerelle egress d'ASM intercepte ces requêtes, les convertit en mTLS et les transmet au service externe. Cette approche supprime le besoin de configurer le TLS au niveau de l'application lors de l'accès à des endpoints externes protégés par mTLS.
Pour les instructions de configuration, consultez la rubrique Utiliser la passerelle egress d'ASM pour accéder à des services mTLS externes.