Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Istio mTLS

cloud

Définition

Le mTLS (mutual TLS) avec Istio est un mécanisme de sécurité des communications entre services dans un service mesh Kubernetes, où chaque service s'authentifie mutuellement via des certificats TLS. Contrairement au TLS unidirectionnel classique (le client vérifie le serveur), le mTLS exige que les deux parties (client ET serveur) présentent un certificat valide, garantissant l'identité des deux côtés de la communication. Istio implémente le mTLS de manière transparente via ses proxies Envoy (sidecars) injectés automatiquement dans chaque pod. Les applications n'ont pas conscience du mTLS : elles communiquent en HTTP/gRPC classique avec le sidecar local, qui se charge de chiffrer et d'authentifier la communication avec le sidecar du service destination. Cette transparence permet d'activer mTLS sans modifier le code des applications. Istio gère son propre système PKI (Public Key Infrastructure) via Istiod (le plan de contrôle Istio). Istiod génère et distribue des certificats X.509 aux proxies Envoy, signés par une CA (Certificate Authority) Istio. Ces certificats encodent l'identité du service sous forme de SPIFFE URI (spiffe://cluster.local/ns/namespace/sa/serviceaccount), permettant une identification précise basée sur le ServiceAccount Kubernetes. Le mode mTLS dans Istio peut être configuré via les ressources PeerAuthentication (définit la politique mTLS pour un namespace ou un service) et DestinationRule (définit le TLS client vers un service spécifique). Le mode STRICT impose le mTLS obligatoire pour toutes les communications (aucun trafic en clair accepté). Le mode PERMISSIVE accepte à la fois le trafic chiffré et non chiffré (pour la migration progressive). L'activation du mTLS strict dans tous les namespaces Kubernetes constitue une implémentation Zero Trust réseau : même si un attaquant compromet un pod ou intercepte le trafic réseau, les communications entre services sont chiffrées et mutuellement authentifiées, rendant les attaques MITM (Man-in-the-Middle) inefficaces.

Migration vers mTLS STRICT

Activez d'abord le mode PERMISSIVE dans tous les namespaces pour permettre au trafic non-mTLS de continuer pendant la migration. Déployez Istio sidecars dans tous les namespaces (istio-injection: enabled). Surveillez via Kiali ou les métriques Envoy que le trafic utilise bien mTLS (indication: connexion_security_policy="mutual_tls"). Une fois tous les services en sidecar, passez en mode STRICT via une PeerAuthentication globale. Le mode STRICT dans kube-system peut casser des sondes de liveness — excluez-le.

Politique d'autorisation Istio (AuthorizationPolicy)

Une fois mTLS activé, utilisez les AuthorizationPolicies Istio pour définir des règles d'accès L7 entre services : autoriser uniquement le service frontend à appeler le service API sur les endpoints GET /api/*, interdire les appels directs vers la base de données depuis les services non autorisés. Les AuthorizationPolicies Istio complémentent les NetworkPolicies Kubernetes en ajoutant une couche d'autorisation applicative basée sur l'identité SPIFFE du service appelant.

Observabilité du trafic chiffré

Istio avec Envoy proxies fournit une observabilité complète du trafic mTLS : métriques (latence, taux d'erreur, volume de trafic), traces distribuées (via Jaeger/Zipkin/Tempo), et logs d'accès Envoy. Kiali visualise graphiquement la topologie des services et l'état du mTLS pour chaque connexion. Cette visibilité est essentielle pour le troubleshooting et la détection d'anomalies dans le trafic inter-services.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis