Cert-manager

Portail > Mise en œuvre et exploitation

cert-manager automatise l'émission et le renouvellement de certificats dans Kubernetes. Il transforme la PKI en ressources déclaratives : on décrit le certificat voulu, cert-manager s'occupe de la CSR, de l'émission et de la rotation.

Modèle de ressources

Ressource	Rôle
Issuer / ClusterIssuer	Définit une source d'émission. Issuer = limité à un namespace ; ClusterIssuer = global.
Certificate	Décrit le certificat souhaité (noms, durée, usages) et le Secret cible.
CertificateRequest	CSR interne générée par cert-manager pour une émission donnée.
Order / Challenge	Spécifiques à ACME : pilotent la validation de contrôle du domaine.

Types d'Issuer : ACME (Let's Encrypt…), CA (à partir d'une paire CA stockée en Secret), Vault (HashiCorp Vault), SelfSigned (utile pour amorcer une CA interne), Venafi, etc.

Cycle interne

<mermaid> flowchart LR

   C[Certificate] --> CR[CertificateRequest]
   CR --> I[Issuer / ClusterIssuer]
   I -->|ACME| O[Order + Challenge]
   O --> S[Secret tls.crt / tls.key]
   I -->|CA / Vault| S

</mermaid>

(Schéma en Mermaid.)

Exemple : Certificate

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: clipsy-tls
  namespace: clipsy
spec:
  secretName: clipsy-tls          # Secret cible (tls.crt = feuille + intermédiaires)
  duration: 2160h                 # 90 jours
  renewBefore: 720h               # renouvellement à J-30
  privateKey:
    rotationPolicy: Always        # nouvelle clé à chaque renouvellement (rekey)
  dnsNames:
    - clipsy.tech
    - www.clipsy.tech
  usages:
    - server auth
  issuerRef:
    name: vault-issuer
    kind: ClusterIssuer

Solveurs ACME (DNS-01 / HTTP-01)

Pour un Issuer ACME, cert-manager prouve le contrôle du domaine via un challenge :

• HTTP-01 : un fichier servi sur /.well-known/acme-challenge/.
• DNS-01 : un enregistrement TXT (seul moyen pour les certificats wildcard) ; nécessite un solveur DNS avec accès API au registrar/zone.
• TLS-ALPN-01 : validation au niveau TLS.

Bonnes pratiques

• renewBefore généreux (1/3 de la durée) pour absorber les incidents.
• rotationPolicy: Always pour changer de clé à chaque renouvellement.
• Rechargement : le Secret est mis à jour, mais beaucoup de charges ne relisent pas à chaud → utiliser un mécanisme de rechargement (reloader) ou un ingress qui recharge.
• trust-manager (projet associé) pour distribuer les bundles de CA (trust stores) dans le cluster.
• Surveiller l'état : kubectl get certificate,certificaterequest -A et les conditions Ready.

Pièges fréquents

• CA interne expirée côté Issuer Vault/CA → toutes les émissions échouent (Dépannage des chaînes de certificats).
• Secret renouvelé mais pod non rechargé → ancien certificat encore servi.
• Réplication du Secret (ESO) non rafraîchie → certificat périmé en aval (Rotation et renouvellement automatisés).

Points clés à retenir

• Modèle déclaratif : Certificate → CertificateRequest → Issuer → Secret.
• Issuers : ACME, CA, Vault, SelfSigned… ClusterIssuer = global.
• DNS-01 obligatoire pour les wildcards.
• Le renouvellement met à jour le Secret ; prévoir le rechargement des consommateurs.

Voir aussi

• Vault PKI
• Rotation et renouvellement automatisés
• CSR et émission d'un certificat
• Dépannage des chaînes de certificats