mTLS pod-to-pod : chiffrer le trafic entre services

Par défaut, le trafic entre Pods Kubernetes circule en clair. N'importe quel Pod dans le cluster peut intercepter les communications d'un autre Pod, il suffit d'un accès réseau. Deux familles d'outils répondent à ce problème, et le syllabus CKS les nomme toutes les deux : le chiffrement transparent de Cilium, qui agit dans le réseau sans que l'application le sache, et le mTLS d'Istio, qui ajoute une identité vérifiable à chaque service. Ce guide vous montre les deux, comment les activer et surtout comment prouver que le trafic est bien chiffré.

Le chiffrement entre Pods relève du domaine Minimize Microservice Vulnerabilities de la CKS, qui pèse 20 % de l'épreuve. La compétence y est formulée ainsi : Implement Pod-to-Pod encryption (Cilium, Istio). Les deux noms y figurent, et ils ne font pas le même travail.

	Cilium en WireGuard	Istio en mTLS
Ce qui chiffre	le datapath du CNI, dans le noyau	un proxy par Pod
Ce que voit l'application	rien, aucun conteneur ajouté	un sidecar, ou un proxy de nœud en mode ambient
Périmètre	tout le trafic entre nœuds	le trafic entre Pods du maillage
Identité de service	non, le chiffrement est au niveau nœud	oui, SPIFFE, utilisable en politique d'accès
Contrôle d'accès par identité	non, cela reste aux NetworkPolicies	oui, AuthorizationPolicy
Activation	une option du chart	un maillage à installer et à injecter

Glissez pour voir

Retenez la ligne qui décide : si le besoin est « que plus rien ne circule en clair », Cilium suffit et coûte une option. Si le besoin est « que le service A puisse appeler B et pas C », il faut une identité de service, donc Istio.

Ce que vous allez apprendre

• Pourquoi le trafic en clair entre Pods est un risque de sécurité
• Comment le mTLS fonctionne (identité SPIFFE, certificats X.509, handshake)
• Configurer Istio pour imposer le mTLS en mode STRICT
• Vérifier que le chiffrement est actif entre deux services
• Contrôler les accès avec AuthorizationPolicy et les principals mTLS
• Choisir entre les approches sidecar et ambient (ztunnel)

Prérequis

• Cluster Kubernetes avec accès administrateur
• Familiarité avec les Pods et les Network Policies
• Compréhension des concepts de service mesh (data plane, control plane)
• istioctl installé (ligne de commande Istio)

Pourquoi chiffrer le trafic entre Pods

Dans un cluster Kubernetes, le réseau est plat par défaut : chaque Pod peut communiquer avec tous les autres Pods sans restriction. Ce modèle simplifie le déploiement, mais crée un risque majeur : si un attaquant compromet un seul Pod, il peut intercepter (sniffing), modifier (man-in-the-middle) ou usurper le trafic des autres services.

Les Network Policies résolvent une partie du problème en filtrant le trafic au niveau L3/L4 (IPs et ports), mais elles ne font ni chiffrement ni authentification. Le tableau ci-dessous clarifie la complémentarité :

Mécanisme	Couche	Chiffrement	Authentification	Ce qu'il contrôle
NetworkPolicy	L3/L4	Non	Non	Quels Pods peuvent se parler (IP/port)
mTLS	L4/L7	Oui (TLS 1.2+)	Oui (certificats X.509)	Qui parle à qui (identité cryptographique)

Glissez pour voir

En combinant les deux, vous obtenez un modèle défense en profondeur : les NetworkPolicies limitent les flux autorisés, et le mTLS garantit que chaque flux est chiffré et que les deux extrémités sont bien qui elles prétendent être.

Kubernetes n'a pas de mTLS natif

Kubernetes ne fournit aucun mécanisme intégré pour chiffrer le trafic entre Pods. Le mTLS du control plane (API server ↔ etcd, kubelet ↔ API server) est un sujet différent. Pour le trafic applicatif entre Pods, vous avez besoin d'un service mesh (Istio, Linkerd, Cilium) ou d'une implémentation manuelle avec des certificats, beaucoup plus complexe à maintenir.

Comment fonctionne le mTLS

Le TLS classique (celui de HTTPS) est unilatéral : seul le client vérifie l'identité du serveur. Le mutual TLS (mTLS) ajoute une étape : le serveur vérifie aussi l'identité du client. Les deux parties présentent un certificat X.509.

Le handshake mTLS, étape par étape

Les cinq étapes ci-dessous décrivent un échange TLS classique auquel on a ajouté une vérification, celle du certificat du client. C'est l'étape 3 qui fait toute la différence : dans une connexion HTTPS ordinaire, le navigateur vérifie le serveur et le serveur ne sait rien du client. En mTLS, chacun prouve son identité à l'autre.

Retenez que tout cela se déroule avant la première requête applicative, et sans aucune modification de votre code : dans un maillage de services, c'est le proxy injecté à côté du conteneur qui exécute ces cinq étapes.

1. Le client initie la connexion TLS : il envoie un "ClientHello" avec les suites de chiffrement qu'il supporte.

2. Le serveur présente son certificat : le client vérifie que le certificat est signé par une autorité de confiance (CA) et que l'identité correspond au service attendu.

3. Le serveur demande le certificat du client : c'est l'étape supplémentaire par rapport au TLS classique. Le client présente son propre certificat.

4. Le serveur vérifie le certificat du client : il confirme que le client est bien un service autorisé, signé par la même CA.

5. La session chiffrée est établie : les deux parties échangent une clé de session symétrique. Tout le trafic suivant est chiffré et authentifié.

Identité SPIFFE

Elle n'est pas théorique, elle se lit dans le proxy. Sur un Pod du namespace lab-mesh utilisant le ServiceAccount default :

kubectl exec <pod> -c istio-proxy -- curl -s localhost:15000/certs | grep -o 'spiffe://[^"]*'

Sortie

spiffe://cluster.local/ns/lab-mesh/sa/default

Le format annoncé plus bas est donc exactement celui que porte le certificat.

Dans un cluster Kubernetes, l'identité de chaque service est encodée dans le certificat sous la forme d'un SPIFFE ID (Secure Production Identity Framework For Everyone). Le format standard est :

spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

Par exemple, un service utilisant le ServiceAccount api-server dans le namespace production aura l'identité :

spiffe://cluster.local/ns/production/sa/api-server

Cette identité basée sur le ServiceAccount Kubernetes est au cœur du modèle de sécurité mTLS. Elle permet de définir des politiques d'accès granulaires : "seul le service frontend dans le namespace production peut appeler le service api-server".

Pourquoi pas les adresses IP ?

Les adresses IP des Pods changent à chaque redéploiement : elles ne sont pas une identité fiable pour le contrôle d'accès. Le SPIFFE ID, lui, est lié au ServiceAccount, une identité stable, indépendante de l'adresse et du nœud.

Le proxy est un sidecar natif, pas un conteneur ordinaire

Relevé sur Istio 1.30.4, un Pod dans un namespace étiqueté istio-injection=enabled :

kubectl get pod app -o jsonpath='{.spec.containers[*].name}'
kubectl get pod app -o jsonpath='{.spec.initContainers[*].name}'

Sortie

app
istio-init istio-proxy

Le proxy est bien là, mais dans les initContainers, avec la signature du sidecar natif :

Sortie

istio-proxy : restartPolicy=Always

C'est ce restartPolicy: Always sur un initContainer qui distingue un sidecar natif d'un simple conteneur d'initialisation : il démarre avant les conteneurs applicatifs, reste en vie pendant toute la durée du Pod, et s'arrête après eux. L'ordre garanti règle au passage un défaut historique des sidecars d'autrefois, l'application qui démarrait avant son proxy et échouait ses premières requêtes.

Istio le documente lui-même dans une annotation du Pod :

Sortie de l'annotation sidecar.istio.io/status

containers      = None
initContainers  = ['istio-init', 'istio-proxy']

Gestion automatique des certificats

Sans maillage de services, il faudrait gérer à la main les certificats de chaque service : génération, distribution, rotation, révocation. Avec un maillage comme Istio, ces quatre opérations sont automatiques.

Étape	Ce qui se passe
Génération	Le proxy (Envoy ou ztunnel) génère une clé privée et envoie une CSR (Certificate Signing Request) au control plane
Signature	Le control plane (istiod) signe la CSR après avoir vérifié l'identité du Pod via le ServiceAccount
Distribution	Le certificat signé est distribué au proxy via l'API SDS (Secret Discovery Service)
Rotation	Les certificats sont renouvelés automatiquement avant expiration (durée par défaut : 24h)

Glissez pour voir

Le code applicatif ne voit rien de tout cela : le proxy gère le mTLS de façon transparente.

Chiffrer avec Cilium, la voie sans sidecar

C'est la solution la plus simple des deux, et celle que le syllabus cite en premier. Cilium chiffre le trafic entre nœuds dans son propre datapath, avec WireGuard : aucun conteneur n'est ajouté aux Pods, aucun manifeste applicatif n'est touché, et l'application ne sait rien de ce qui se passe.

Le prérequis est d'avoir Cilium comme CNI. Son installation et ses concepts sont traités dans le guide dédié, Cilium, le CNI eBPF.

Activer le chiffrement WireGuard

Deux options du chart suffisent, à poser à l'installation ou par une mise à jour :

helm upgrade --install cilium cilium/cilium --version 1.20.1 \
  --namespace kube-system \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

Relevé en lab sur Cilium 1.20.1 et Kubernetes 1.37 : l'installation complète prend 53 secondes et les nœuds passent Ready dans la foulée.

Changer l'option ne suffit pas à changer le comportement

La configuration de Cilium vit dans une ConfigMap, pas dans le gabarit du DaemonSet. Une mise à jour Helm qui bascule encryption.enabled modifie donc la ConfigMap sans déclencher de redémarrage : kubectl rollout status annonce un succès, et les agents continuent d'appliquer l'ancienne valeur, qu'ils ont lue au démarrage. Il faut un kubectl -n kube-system rollout restart ds/cilium pour que le changement prenne effet.

Vérifier que le chiffrement est actif

C'est le geste attendu à l'examen, et il ne consiste pas à relire l'option :

kubectl -n kube-system exec ds/cilium -c cilium-agent -- cilium-dbg status | grep -i encryption

Sortie

Encryption: Wireguard [NodeEncryption: Disabled,
  cilium_wg0 (Pubkey: v38E2wsPmrYwEnN5Y9rRs/..., Port: 51871, Peers: 1)]

Trois informations utiles dans cette ligne. Le chiffrement est bien en WireGuard, il passe par une interface cilium_wg0 sur le port 51871/UDP, et le nombre de pairs doit valoir le nombre d'autres nœuds du cluster. Un Peers: 0 sur un cluster multi-nœuds signale que les nœuds ne se sont pas appariés.

NodeEncryption: Disabled n'est pas une anomalie, c'est le défaut. Le trafic entre Pods est chiffré ; le trafic émis par les nœuds eux-mêmes ne l'est qu'en activant encryption.nodeEncryption=true, ce qui est un réglage distinct et plus intrusif.

La preuve qui compte : observer le tunnel

Une option activée et un statut vert ne prouvent pas qu'un octet est passé par le tunnel. Le compteur de l'interface, lui, le prouve. Deux séries de 40 requêtes HTTP depuis un même Pod client, l'une vers un Pod du même nœud, l'autre vers un Pod d'un nœud différent :

# Sur le nœud, avant et après chaque série
cat /sys/class/net/cilium_wg0/statistics/tx_bytes

Destination	Octets sortis par cilium_wg0
Pod du même nœud	0
Pod d'un autre nœud	42 880

Glissez pour voir

Le résultat dit exactement ce que fait WireGuard ici : il chiffre ce qui quitte la machine. Deux Pods colocalisés communiquent sans jamais toucher au tunnel, ce qui est logique, leur trafic ne passe sur aucun câble.

Mesurer par adresse IP, pas par nom de service

La première version de cette mesure donnait 14 080 octets pour du trafic censé rester sur le nœud. La cause n'était pas le chiffrement mais le DNS : les Pods CoreDNS tournaient sur l'autre nœud, et chaque curl http://serveur commençait par une résolution qui, elle, traversait bien le tunnel. Viser directement l'adresse IP du Pod supprime cette résolution et rend la mesure lisible.

Le contrôle négatif achève la démonstration. Après --set encryption.enabled=false et un redémarrage des agents, cilium-dbg status affiche Encryption: Disabled, l'interface a disparu (Device "cilium_wg0" does not exist), et le trafic entre les deux mêmes Pods passe toujours, en HTTP 200. Le chiffrement n'a donc jamais été une condition de fonctionnement, seulement une propriété du transport.

Ce que Cilium ne vous donne pas

Le chiffrement transparent protège la confidentialité sur le fil. Il ne donne aucune identité de service : pour Cilium, un Pod est une identité de sécurité dérivée de ses labels, que l'on filtre avec des NetworkPolicies. Si vous devez répondre à « le service A a-t-il le droit d'appeler B », c'est l'autre voie qu'il vous faut, et c'est l'objet de toute la suite de cette page.

Activer le mTLS avec Istio

Istio est le service mesh le plus répandu et le plus fréquemment référencé dans le contexte CKS. Il propose deux modèles de déploiement : le mode sidecar classique et le mode ambient (sans sidecar). Dans les deux cas, le mTLS se configure avec les mêmes ressources Kubernetes.

Installer Istio

Cette section installe Istio pour que vous puissiez pratiquer, mais l'installation elle-même n'est pas évaluée à la CKS : les clusters d'examen ont déjà le maillage en place. Vous pouvez donc la parcourir rapidement si vous révisez, et y revenir quand vous monterez votre propre environnement. La documentation Istio couvre les options que ce guide ne détaille pas.

Pour un cluster de lab, l'installation minimale avec le profil demo :

# Télécharger istioctl
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.29.1 sh -
cd istio-1.29.1
export PATH=$PWD/bin:$PATH

# Installer avec le profil demo (inclut ingress + egress gateways)
istioctl install --set profile=demo -y

Vérification :

kubectl get pods -n istio-system

Résultat attendu, istiod et les gateways doivent être Running :

NAME                                    READY   STATUS    RESTARTS   AGE
istio-egressgateway-6bbb4c99b5-69jw8    1/1     Running   0          80s
istio-ingressgateway-8574598487-pjhrq   1/1     Running   0          79s
istiod-857888d8dd-6zt2t                 1/1     Running   0          92s

Injecter les proxies sidecar

En mode sidecar, Istio injecte un proxy Envoy dans chaque Pod. Pour activer l'injection automatique sur un namespace :

kubectl label namespace default istio-injection=enabled

Tout Pod créé dans ce namespace contiendra désormais deux conteneurs : votre application et le proxy Envoy.

Le mode ambient, sans sidecar

Depuis Istio 1.22, une seconde architecture coexiste avec les sidecars et change le compromis. Le mode ambient remplace le proxy injecté dans chaque Pod par un ztunnel, déployé une fois par nœud en DaemonSet. Le chiffrement et l'authentification L4 sont assurés sans qu'aucun Pod applicatif soit modifié, ce qui supprime l'injection, le redémarrage des charges et la consommation d'un conteneur supplémentaire par Pod.

Son activation tient à un label sur le namespace :

kubectl label namespace default istio.io/dataplane-mode=ambient

La contrepartie est à connaître avant de choisir : le ztunnel ne couvre que le niveau L4. Dès que vous avez besoin de fonctionnalités L7, routage HTTP ou AuthorizationPolicy portant sur des chemins d'URL, il faut ajouter un waypoint proxy par namespace, et le gain de simplicité se réduit d'autant.

PeerAuthentication : imposer le mTLS

La ressource PeerAuthentication contrôle le mode mTLS pour un namespace ou un workload spécifique. C'est la ressource clé pour la CKS.

Trois modes sont disponibles :

Mode	Comportement	Usage
PERMISSIVE	Accepte le trafic mTLS et en clair	Migration progressive (défaut Istio)
STRICT	Accepte uniquement le trafic mTLS	Production sécurisée
DISABLE	Désactive le mTLS	Déconseillé sauf cas très spécifique

Glissez pour voir

mTLS STRICT sur tout le mesh

Pour imposer le chiffrement sur tous les namespaces du cluster :

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system   # namespace racine = s'applique à tout le mesh
spec:
  mtls:
    mode: STRICT

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

mTLS STRICT sur un namespace

Pour appliquer le mode STRICT uniquement sur le namespace production :

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

mTLS sur un workload spécifique

Pour cibler un workload précis avec un selector :

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: api-strict
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-server
  mtls:
    mode: STRICT

Ordre de priorité des PeerAuthentication

Istio applique la politique la plus spécifique. Si plusieurs PeerAuthentication existent, la hiérarchie est : workload-specific > namespace > mesh-wide. En cas de conflit, c'est la politique la plus proche du workload qui l'emporte.

AuthorizationPolicy : contrôle d'accès basé sur l'identité

Le mTLS en mode STRICT garantit que tout le trafic est chiffré et authentifié. Mais il ne contrôle pas qui peut appeler quoi. C'est le rôle de l'AuthorizationPolicy.

Grâce au mTLS, Istio connaît l'identité SPIFFE de chaque requête. Vous pouvez exploiter cette information pour définir des règles d'accès granulaires.

Autoriser uniquement certains services

L'exemple suivant autorise uniquement le service frontend (via son ServiceAccount) à accéder au service api-server :

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: api-server-access
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-server
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/frontend"

Le champ principals utilise le SPIFFE ID du service source. Sans mTLS en mode STRICT, ce champ ne fonctionne pas (Istio ne peut pas extraire l'identité d'un flux en clair).

Politique deny-by-default

Pour un namespace en mode "zero trust", commencez par refuser tout le trafic, puis ouvrez explicitement les flux autorisés :

# Étape 1 : refuser tout par défaut
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  action: ALLOW
  # Pas de rules → ne match jamais → tout est refusé

Un service qui tente d'appeler api-server reçoit désormais une erreur HTTP 403 :

RBAC: access denied

# Étape 2 : autoriser explicitement le flux frontend → api-server
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-server
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/frontend"
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]

Un réflexe à garder pour l'examen comme pour la production : appliquez le principe du moindre privilège dans cet ordre précis. Posez d'abord une politique qui refuse tout, puis autorisez explicitement chaque flux nécessaire en désignant les appelants par leur principal SPIFFE. Ce qui est évalué n'est pas la syntaxe mais la compréhension de la chaîne : une PeerAuthentication en STRICT garantit que l'identité est prouvée, une AuthorizationPolicy décide ensuite de ce que cette identité a le droit de faire.

Le passage en STRICT, éprouvé

C'est l'affirmation centrale de cette page, et elle se prouve avec trois mesures sur le même cluster. Un serveur dans un namespace du maillage, un client hors maillage, un client dans le maillage.

Situation	Mode PeerAuthentication	Résultat
Client hors maillage	PERMISSIVE (défaut)	HTTP 200
Client hors maillage	STRICT	échec, curl sort en 56
Client dans le maillage	STRICT	HTTP 200

Glissez pour voir

Le code 56 de curl signifie « échec de réception des données réseau » : la connexion TCP s'établit, puis le proxy la coupe faute de certificat client. Ce n'est donc pas un refus HTTP, et c'est pourquoi aucun code de statut n'apparaît. Un client qui attendait un 403 cherchera longtemps.

La bascule entre les deux lignes du milieu ne demande qu'un objet :

peerauth-strict.yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict
  namespace: production
spec:
  mtls:
    mode: STRICT

Vérifier que le mTLS est actif

Après avoir configuré le mTLS, vous devez pouvoir vérifier qu'il fonctionne réellement. Istio fournit plusieurs méthodes de vérification.

Vérifier la configuration avec istioctl

# Voir la politique mTLS effective pour un workload
istioctl x describe pod <pod-name> -n <namespace>

Exemple de sortie :

Pod: api-server-5b7c5fd757-4jmtj
   Pod Revision: default
   Pod Ports: 80 (nginx)
--------------------
Service: api-server
   Port:  8080/auto-detect targets pod port 80
--------------------
Effective PeerAuthentication:
   Workload mTLS mode: STRICT
Applied PeerAuthentication:
   default.production

La sortie indique les politiques PeerAuthentication appliquées et le mode mTLS effectif sur le workload.

Vérifier le certificat d'un proxy

# Inspecter le certificat utilisé par le proxy Envoy d'un Pod
istioctl proxy-config secret <pod-name> -n <namespace>

La sortie affiche les certificats actifs, leur validité et leur numéro de série :

RESOURCE NAME     TYPE           STATUS     VALID CERT     SERIAL NUMBER                        NOT AFTER                NOT BEFORE
default           Cert Chain     ACTIVE     true           a082e25c3b111ace6e53f6b9891ab30d     2026-03-28T09:14:48Z     2026-03-27T09:12:48Z
ROOTCA            CA             ACTIVE     true           c253fd7d7a186f43c1e200c5c8513835     2036-03-24T09:12:25Z     2026-03-27T09:12:25Z

La ligne default porte le certificat mTLS de la charge de travail, SPIFFE ID compris. La ligne ROOTCA est l'autorité de certification racine d'Istio.

Tester le rejet du trafic en clair

Pour confirmer que le mode STRICT fonctionne, tentez d'envoyer du trafic en clair depuis un Pod sans proxy vers un service protégé :

# Depuis un namespace sans injection sidecar
kubectl create namespace no-mesh
kubectl run test-clear --image=curlimages/curl:8.21.0@sha256:7c12af72ceb38b7432ab85e1a265cff6ae58e06f95539d539b654f2cfa64bb13 --rm -it --restart=Never -n no-mesh \
  -- curl -s -o /dev/null -w "HTTP %{http_code}\n" --max-time 5 http://api-server.production.svc.cluster.local:8080

Résultat attendu avec mTLS STRICT :

HTTP 000
pod "test-clear" deleted
pod no-mesh/test-clear terminated (Error)

Le code HTTP 000 et l'exit code curl 56 (connection reset by peer) confirment que le proxy côté serveur rejette tout trafic non-mTLS. La connexion TCP s'établit mais le handshake TLS échoue.

Vérifier dans les métriques

# Les métriques Istio indiquent le type de connexion
istioctl dashboard prometheus

La métrique istio_tcp_connections_opened_total avec le label connection_security_policy="mutual_tls" confirme que les connexions sont chiffrées.

Migration progressive : PERMISSIVE vers STRICT

Activer le mTLS STRICT d'un coup sur un cluster existant casse les services qui n'ont pas encore de proxy. La migration se fait en trois étapes, et chacune se vérifie avant de passer à la suivante.

1. Vérifier l'injection des proxies : assurez-vous que tous les namespaces applicatifs ont l'injection sidecar activée et que tous les Pods ont redémarré avec leur proxy.

   Attention à la commande employée. Depuis Istio 1.30, le proxy est injecté comme sidecar natif : il vit dans spec.initContainers avec restartPolicy: Always, et plus du tout dans spec.containers. Une vérification qui lit containerStatuses ne le voit donc pas et laisse croire à un échec d'injection.

   # ❌ ne voit plus le proxy depuis Istio 1.30
   kubectl get pods -n production -o jsonpath='{.items[*].spec.containers[*].name}'
   
   # ✅ le label posé par l'injecteur, indépendant de l'emplacement du conteneur
   kubectl get pods -n production -l security.istio.io/tlsMode=istio

   kubectl get pods affiche toujours 2/2 : les sidecars natifs comptent dans la colonne READY. C'est seulement l'inspection par champ qui change d'adresse.

2. Activer le mode PERMISSIVE (défaut) : ce mode accepte le trafic mTLS et en clair. Les services avec proxy communiquent déjà en mTLS entre eux, et les services sans proxy continuent de fonctionner.

   istioctl x describe pod <pod-name> -n production

   Vérifiez que les connexions entre Pods avec proxy utilisent bien mTLS.

3. Passer en mode STRICT : une fois que tous les Pods ont un proxy, basculez en STRICT. Surveillez les erreurs de connexion dans les logs.

   kubectl apply -f - <<EOF
   apiVersion: security.istio.io/v1
   kind: PeerAuthentication
   metadata:
     name: default
     namespace: production
   spec:
     mtls:
       mode: STRICT
   EOF

Dépannage

Les pannes du mTLS ont une signature commune : le trafic passait avant, il ne passe plus, et l'application ne dit pas pourquoi puisque le refus a lieu dans le proxy, pas dans votre code. Le réflexe est donc de chercher du côté de l'injection du sidecar et de l'identité présentée, jamais du côté applicatif.

Le tableau se lit en partant du symptôme exact, message d'erreur compris : deux causes très différentes produisent des erreurs de connexion qui se ressemblent, et c'est le libellé précis qui les sépare.

Symptôme	Cause probable	Solution
connection reset by peer depuis un Pod sans proxy	Le service cible est en mTLS STRICT et rejette le trafic en clair	Injecter le sidecar Istio dans le Pod source, ou passer temporairement en PERMISSIVE
upstream connect error or disconnect	Le proxy n'a pas encore reçu son certificat	Vérifier les logs d'istiod : kubectl logs -n istio-system deploy/istiod | grep -i error
AuthorizationPolicy refuse des requêtes légitimes	Le principal SPIFFE dans la règle ne correspond pas au ServiceAccount réel	Vérifier l'identité : istioctl proxy-config secret <pod> et comparer avec le champ principals
Les métriques ne montrent pas mutual_tls	L'injection sidecar n'est pas active sur le namespace	Vérifier le label : kubectl get ns <ns> --show-labels | grep istio
Latence élevée après activation du mTLS	Le handshake TLS ajoute de la latence sur les premières requêtes	Normal pour les connexions courtes. Les connexions persistantes (keep-alive) amortissent le coût. Envisager le mode ambient (ztunnel) pour une empreinte plus légère

Glissez pour voir

À retenir

• Le trafic entre Pods est en clair par défaut dans Kubernetes, le mTLS est indispensable pour le chiffrer et authentifier.
• Le mTLS vérifie l'identité des deux extrémités via des certificats X.509, contrairement au TLS classique qui ne vérifie que le serveur.
• L'identité est basée sur le SPIFFE ID (spiffe://cluster.local/ns/<namespace>/sa/<service-account>), liée au ServiceAccount Kubernetes.
• PeerAuthentication contrôle le mode mTLS (PERMISSIVE, STRICT, DISABLE). Le mode STRICT est requis en production.
• AuthorizationPolicy avec des principals SPIFFE permet un contrôle d'accès granulaire basé sur l'identité cryptographique des services.
• Le mTLS et les NetworkPolicies sont complémentaires : l'un chiffre et authentifie, l'autre filtre les flux réseau.
• La rotation des certificats est automatique avec un service mesh, aucune intervention manuelle nécessaire.
• Pour la CKS, la compétence s'énonce Implement Pod-to-Pod encryption (Cilium, Istio) : sachez activer et vérifier les deux.
• Côté Cilium, retenez la chaîne : encryption.type=wireguard → redémarrage des agents → cilium-dbg status → compteur de cilium_wg0.
• Côté Istio, maîtrisez la chaîne : injection proxy → PeerAuthentication STRICT → AuthorizationPolicy → principals SPIFFE.

Pour aller plus loin

• Audit Logs : La traçabilité côté API server, complément du chiffrement du trafic entre Pods.
• Runtime Sandboxes (gVisor, Kata) : L'isolation du noyau pour les charges dont le trafic est déjà chiffré.

Quiz

Dix questions sur le chiffrement du trafic entre Pods : identite SPIFFE, PeerAuthentication, AuthorizationPolicy et diagnostic du handshake.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →