MTLS dans le cluster
Portail > Mise en œuvre et exploitation
Le mTLS (TLS mutuel) authentifie les deux extrémités d'une connexion par certificat. À l'échelle d'un cluster, chaque charge de travail reçoit une identité cryptographique courte ; SPIFFE/SPIRE et les service mesh industrialisent cette distribution.
TLS mutuel : rappel
En TLS classique, seul le serveur présente un certificat. En mTLS, le client en présente un aussi : le serveur valide la chaîne du client et son EKU clientAuth. Cela authentifie les services entre eux sans mots de passe.
Le défi à l'échelle
Des centaines de pods éphémères : émettre, distribuer, renouveler et révoquer des certificats manuellement est impossible. Il faut des identités automatiques, à très court TTL, rattachées à une CA interne.
SPIFFE / SPIRE
SPIFFE est une norme d'identité de charge de travail ; SPIRE en est l'implémentation.
| Notion | Description |
|---|---|
| SPIFFE ID | Identité sous forme d'URI : spiffe://trust-domain/ns/clipsy/sa/api.
|
| SVID | Le document portant l'identité : un certificat X.509 (X.509-SVID) ou un JWT. |
| Trust domain | Racine de confiance d'un périmètre ; chaque domaine a sa CA. |
| Workload API | API locale par laquelle un service obtient son SVID et le bundle de confiance, sans secret pré-distribué. |
Le SPIFFE ID est porté par le SAN de type URI du certificat. SPIRE atteste l'identité du nœud et de la charge (node/workload attestation) avant de délivrer le SVID, qu'il renouvelle automatiquement à TTL court.
Service mesh
Istio, Linkerd et consorts activent le mTLS de façon transparente : un proxy (sidecar ou proxy de nœud) reçoit un certificat d'identité (souvent basé SPIFFE) et chiffre/authentifie le trafic entre services sans modifier les applications. La CA du mesh est interne au cluster.
Approche cert-manager
- csi-driver de cert-manager : monte des certificats courts directement dans les pods, renouvelés à l'expiration.
- Émission via un Issuer Vault ou une CA interne, pour une identité de charge de travail.
Identité ≠ réseau
Le mTLS authentifie qui parle (identité forte), pas seulement d'où vient le trafic (IP/réseau). C'est la base d'une posture zero trust : on n'accorde pas la confiance par localisation réseau mais par identité vérifiée cryptographiquement.
Bonnes pratiques
- TTL très courts (heures) → révocation quasi inutile, rotation permanente.
- Un trust domain par périmètre ; relier plusieurs domaines par fédération (cross-signing/bundles).
- Vérifier l'EKU
clientAuthcôté serveur, et valider le SPIFFE ID attendu, pas seulement la chaîne.
Points clés à retenir
- mTLS = authentification mutuelle par certificat (EKU clientAuth côté client).
- SPIFFE (norme) / SPIRE (implémentation) : identité de charge via SVID, SPIFFE ID dans le SAN URI, renouvellement auto à TTL court.
- Les service mesh activent le mTLS de façon transparente.
- On authentifie l'identité, pas la position réseau → zero trust.