mTLS¶

Authentification mutuelle entre services — chaque composant prouve son identité.

TLS vs mTLS¶

Dans un TLS classique, seul le serveur présente un certificat. Le client vérifié l'identité du serveur, mais le serveur ne sait pas qui est le client. Dans un contexte de microservices ou le réseau interne ne peut pas être considéré comme sur, cette asymétrie est un risque.

Le mTLS (mutual TLS) exige que les deux parties presentent et valident un certificat. Chaque service a une identité cryptographique prouvable. Un service qui ne peut pas présenter un certificat valide est refuse — même s'il est sur le même réseau, dans le même cluster, dans le même namespace.

sequenceDiagram
    participant A as Service A
    participant B as Service B

    A->>B: ClientHello
    B->>A: ServerHello + certificat serveur
    A->>A: Verifier certificat serveur (CA interne)
    A->>B: Certificat client
    B->>B: Verifier certificat client (CA interne)
    A->>B: Communication chiffree etablie
    B->>A: Reponse chiffree

La différence fondamentale : en TLS classique, le serveur est vérifié. En mTLS, les deux parties sont verifiees. C'est la base de l'identité de workload dans un modèle zero trust.

Architecture PKI interne¶

Le mTLS à l'échelle nécessité une infrastructure a clés publiques (PKI) interne. Les certificats publics (Let's Encrypt, DigiCert) ne sont pas adaptés à l'authentification de workloads internes — ils valident des noms de domaine publics, pas des identités de services.

Composants d'une PKI interne¶

graph TD
    ROOT["Root CA\n(offline, HSM)"]
    INT["Intermediate CA\n(operationnelle)"]
    SVC1["Certificat\nService A"]
    SVC2["Certificat\nService B"]
    SVC3["Certificat\nService C"]

    ROOT --text--> INT
    INT --text--> SVC1
    INT --text--> SVC2
    INT --text--> SVC3

Root CA — l'autorité de certification racine. Elle signe l'intermediate CA, jamais directement les certificats de service. Stockee offline, idealement dans un HSM (Hardware Security Module). Sa compromission invalide toute la chaîne de confiance.

Intermediate CA — l'autorité opérationnelle qui emet les certificats de service. Si elle est compromise, on la revoque et on en deploie une nouvelle sans toucher à la root CA. En production, on peut avoir plusieurs intermediate CA pour des environnements différents (production, staging, dev).

Certificats de service — emis par l'intermediate CA, identifiés par un SAN (Subject Alternative Name) ou un SPIFFE ID. Durée de vie courte, rotation automatique.

Hiérarchie a deux niveaux¶

La hiérarchie a deux niveaux (root + intermediate) est le minimum recommande. Elle offre :

• Isolation — la root CA reste offline et protégée
• Rotation — on peut renouveler l'intermediate CA sans changer la root
• Segmentation — une intermediate CA par environnement ou par équipe
• Revocation — revoquer une intermediate CA n'affecte qu'une partie de l'infrastructure

Gestion du cycle de vie des certificats¶

La complexité du mTLS reside dans la gestion des certificats à l'échelle. Avec des centaines de services, la gestion manuelle est impossible et dangereuse.

Émission¶

L'émission des certificats doit être automatisee. Un service ne devrait jamais avoir a demander manuellement un certificat. Au démarrage, le service reçoit automatiquement son certificat depuis la PKI.

Rotation¶

La rotation régulière limite l'impact d'une compromission. Un certificat avec une durée de vie de 24h compromis est exploitable pendant 24h au maximum. Un certificat avec une durée de vie de 1 an est exploitable pendant 1 an.

La rotation doit être transparente pour le service — pas de downtime, pas d'intervention manuelle. Le nouveau certificat est déployé avant l'expiration de l'ancien. Les deux coexistent brievement pour éviter les interruptions.

gantt
    title Rotation de certificat (overlap)
    dateFormat HH:mm
    section Cert A
    Actif           :a1, 00:00, 24h
    section Cert B
    Emission        :b0, 22:00, 1h
    Actif           :b1, 23:00, 24h

Revocation¶

En cas de compromission d'un service, son certificat doit pouvoir être revoque immédiatement. Deux mécanismes :

CRL (Certificate Revocation List) — une liste de certificats revoques publiee périodiquement par la CA. Simple mais avec un délai — les clients ne verifient la CRL que périodiquement.

OCSP (Online Certificate Status Protocol) — vérification en temps réel du statut d'un certificat aupres de la CA. Plus reactif mais ajoute une dépendance réseau à chaque connexion.

OCSP Stapling — le serveur joint une réponse OCSP récente a sa réponse TLS, éliminant le besoin pour le client de contacter l'OCSP responder. Meilleur compromis performance/sécurité.

La tendance actuelle est aux certificats a durée de vie très courte (quelques heures) qui rendent la revocation quasi inutile — le certificat expire avant que la revocation ne soit nécessaire.

cert-manager et rotation automatique¶

cert-manager est le standard de facto pour la gestion des certificats dans Kubernetes. Il automatise l'émission, le renouvellement et la rotation des certificats TLS.

Architecture cert-manager¶

graph LR
    CM["cert-manager\ncontroller"] --text--> ISSUER["Issuer\n(Vault, self-signed, ACME)"]
    ISSUER --text--> CERT["Certificate"]
    CERT --text--> SECRET["Secret K8s\n(tls.crt + tls.key)"]
    POD["Pod applicatif"] --mount--> SECRET

Configuration type¶

# Issuer connecte a HashiCorp Vault
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: vault-issuer
spec:
  vault:
    server: https://vault.internal:8200
    path: pki/sign/workload
    auth:
      kubernetes:
        role: cert-manager
        mountPath: /v1/auth/kubernetes

---
# Certificat avec rotation automatique
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: order-service-tls
  namespace: production
spec:
  secretName: order-service-tls
  duration: 24h
  renewBefore: 4h
  issuerRef:
    name: vault-issuer
    kind: ClusterIssuer
  commonName: order-service
  dnsNames:
    - order-service
    - order-service.production.svc.cluster.local

Le champ renewBefore est critique — il définit la fenêtre de renouvellement. Avec duration: 24h et renewBefore: 4h, le certificat est renouvele 4 heures avant son expiration, garantissant une continuite de service.

SPIFFE et identités de workload¶

SPIFFE (Secure Production Identity Framework For Everyone) définit un standard pour les identités de workload. Chaque workload reçoit un SPIFFE ID — un URI unique qui l'identifié independamment de son emplacement réseau.

Format : spiffe://trust-domain/path

Exemple : spiffe://acme.com/production/order-service

SPIRE est l'implémentation de référence de SPIFFE. Il géré l'émission et la rotation des identités SPIFFE sous forme de certificats X.509 ou de JWT.

Quand utiliser le mTLS¶

Le mTLS est particulièrement adapté aux communications service-a-service dans un environnement de microservices. Pour les communications client-serveur (navigateur, app mobile), il n'est généralement pas applicable — les clients ne disposent pas de certificats gérés centralement.

Approche hybride¶

Une approche hybride courante : mTLS entre tous les services internes, JWT ou OAuth2 pour les clients externes. Le JWT prouve l'identité de l'utilisateur, le mTLS prouve l'identité du service appelant.

graph LR
    BROWSER[Navigateur] --text--> GW[API Gateway]
    GW --text--> SVC_A[Service A]
    SVC_A --text--> SVC_B[Service B]
    SVC_B --text--> DB[(Database)]

Service mesh transparent¶

Le service mesh (Istio, Linkerd) peut prendre en charge le mTLS de façon transparente — sans modifier le code applicatif. Chaque sidecar proxy géré la negociation TLS, la vérification des certificats et le reporting.

Le mesh peut opérer en deux modes :

• Permissif — mTLS optionnel pendant la migration (accepte les connexions non-mTLS)
• Strict — mTLS obligatoire, les connexions non-mTLS sont refusees

Debugging et observabilité mTLS¶

Le mTLS ajoute une couche de complexité au diagnostic des problèmes de communication entre services. Quelques outils et techniques pour faciliter le debugging.

Erreurs courantes¶

Outils de diagnostic¶

# Verifier le certificat d'un service (depuis un pod)
openssl s_client -connect order-service:8080 \
  -cert /certs/tls.crt -key /certs/tls.key \
  -CAfile /certs/ca.crt

# Inspecter un certificat
openssl x509 -in /certs/tls.crt -text -noout

# Verifier l'expiration
openssl x509 -in /certs/tls.crt -enddate -noout

Observabilité dans le service mesh¶

Avec un service mesh, le mTLS est transparent pour l'application mais visible dans les métriques du sidecar :

• Connexions mTLS reussies / échouées — métriques Envoy/Linkerd
• Certificats proches de l'expiration — alertes cert-manager
• Handshake latency — impact du mTLS sur la latence des requêtes (généralement < 1ms après le premier handshake grâce au session resumption)

Le monitoring des certificats est critique. Une alerte doit se déclencher bien avant l'expiration — au minimum 2x la periode de renouvellement. Si renewBefore est a 4h, l'alerte doit se déclencher a 8h avant l'expiration.

Chapitre suivant : Supply chain security — garantir l'intégrité de la chaîne d'approvisionnement, de la source au déploiement.