1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Tu as sécurisé ta chaîne CI.
Tu surveilles le runtime avec Defender.
Mais il reste un angle mort, souvent découvert dans l’urgence : la gestion des certificats

  • ➡️ Tu as déjà vu un Ingress échouer parce qu’un certificat avait expiré ?
  • ➡️ Ou une exposition publique bloquée, car le DNS n’était pas validé à temps ?

La gestion manuelle des certificats, même avec des CA publiques comme Let’s Encrypt, reste un point de friction majeur entre les équipes Dev, Réseau et Sécurité.

Et pourtant : ce processus peut être entièrement automatisé dans Kubernetes.

C’est exactement ce que permet Cert-Manager :

  • Génération automatique des certificats,
  • Validation DNS autonome (via Gandi, AzureDNS, etc.),
  • Renouvellement à l’expiration,
  • Et intégration avec Key Vault pour renforcer la sécurité.

Ce n’est pas juste un confort.
C’est un accélérateur DevSecOps, qui permet de fiabiliser l’exposition sécurisée de tes services, sans scripts, sans tickets, sans oubli.

Dans cette 6e et dernière partie, on verra :

  • Comment Cert-Manager s’intègre dans Kubernetes et avec Azure DNS,
  • Pourquoi il ne fonctionne pas avec les zones privées,
  • Et dans quels cas il faut basculer vers une gestion manuelle (PKI + Key Vault).

💡 L’objectif : ne plus jamais découvrir une expiration de certificat par un bug en prod

7. Cert Manager

Historiquement, demander un certificat ou un enregistrement DNS a toujours été une source de friction.
Entre les équipes développement qui ont besoin d’un certificat pour exposer leur service, et les équipes réseau ou sécurité qui gèrent l’attribution DNS et les certificats SSL, il y a… un gouffre de tickets, d’attentes, et de relectures.

👉 Cert-Manager vient combler ce fossé, en automatisant complètement la gestion des certificats dans Kubernetes.

Cert-Manager permet à un développeur :

  • De demander un certificat (TLS/SSL),
  • De créer un enregistrement DNS de validation,
  • Et de laisser le cluster faire le reste.

Plus besoin d’aller “voir les réseaux” pour chaque domaine ou certificat.
Le besoin est exprimé dans un simple objet YAML de type :

  • Issuer ou ClusterIssuer
  • Certificate
  • CertificateRequest

Et Cert-Manager se charge ensuite de :

  • Gérer la validation du domaine (DNS-01 ou HTTP-01),
  • Générer le certificat via un fournisseur public ou interne,
  • Le renouveler automatiquement à expiration,
  • Et surtout : le supprimer proprement quand l’application disparaît.

💡 Cycle de vie = 100 % automatisé, plus de certificats « orphelins »

Cert-Manager est un projet open source largement adopté, pensé dès le départ pour fonctionner dans des environnements Kubernetes, avec des intégrations :

  • DNS : Cloudflare, Google DNS, Gandi, Route 53, Azure DNS…
  • ACME / Let’s Encrypt
  • Et de nombreux CA internes ou externes.

Dans notre cas, l’usage de AzureDNS comme autorité de certification (et fournisseur DNS) est parfaitement compatible.
Cela signifie que :

  • Les certificats publics peuvent être délivrés de manière automatisée,
  • Et les validations DNS peuvent être gérées par Cert-Manager, sans intervention manuelle.

Un autre avantage clé de Cert-Manager, c’est sa capacité à s’intégrer avec une large gamme de fournisseurs DNS, ce qui le rend extrêmement flexible pour des environnements hybrides, distribués ou multisites

⚠️ Important : toutes les intégrations listées ici ne fonctionnent que pour les zones DNS publiques. Pour les zones privées, voir section 7.4.

Parmi les intégrations officiellement prises en charge, on retrouve :

  • AzureDNS (zones publiques uniquement)
  • Amazon Route 53
  • Cloudflare
  • Google Cloud DNS
  • DigitalOcean
  • Akamai
  • ACMEDNS
  • Gandi
  • (Et de nombreux autres via des plugins ou providers personnalisés)

Cela permet à Cert-Manager de fonctionner dans presque toutes les configurations cloud ou multi-cloud, avec une automatisation de la validation DNS quelle que soit la zone concernée.

Dans notre configuration, les certificats publics sont gérés via AzureDNS (zones publiques). Cert-Manager est capable de :

  • Créer les enregistrements DNS de validation,
  • Obtenir et renouveler automatiquement les certificats.

C’est idéal pour :

  • Des API publiques,
  • Des portails d’authentification,
  • Des intégrations tierces.

📌 À retenir : Cert-Manager est efficace uniquement avec des zones DNS publiques.


Cert-Manager s’intègre nativement avec la majorité des fournisseurs DNS du marché, à condition que la zone soit publique et accessible depuis l’extérieur.

Pour les environnements nécessitant des certificats publics avec validation DNS automatisée, c’est une solution mature, modulaire et largement éprouvée.

Avant qu’un certificat puisse être émis, encore faut-il prouver que l’on est bien propriétaire du domaine concerné.
C’est le rôle des challenges de validation définis par le protocole ACME (Automated Certificate Management Environment).

ChallengeFonctionnementCas d’usage
HTTP-01Fichier exposé sur une URL publiqueFacile pour services déjà accessibles
DNS-01Enregistrement TXT dans la zone DNS publiqueRecommandé pour wildcard ou services non exposés

Cert-Manager sait automatiser ces challenges à condition que la zone DNS soit publique et supportée.

Par défaut, une fois le certificat émis :

  • Il est stocké dans un Secret Kubernetes (type TLS), contenant à la fois le certificat et sa clé privée , ce qui peut poser un problème de conformité en environnement sensible

Pour plus de sécurité, on peut également utiliser :

  • Le CSI Driver (Container Storage Interface),
    qui permet de ne jamais stocker la clé privée dans Kubernetes, mais uniquement en mémoire sur le nœud.
    👉 Cela renforce significativement la sécurité sur des environnements sensibles.

⚠️ Le point bloquant majeur pour l’usage de Cert-Manager en environnement sécurisé réside dans la nécessité d’exposer les preuves publiquement.

Les challenges ACME ne fonctionnent que sur des zones DNS publiques.

C’est une limitation structurelle du protocole, pas de l’outil.

  • Impossible d’émettre automatiquement des certificats via Cert-Manager pour des applications internes,
    hébergées sur des zones DNS privées Azure ou non résolubles publiquement.
  • Dans ces cas, il faudra passer par une PKI interne, et gérer manuellement :
    • La génération des CSR
    • La signature via la CA
    • Le renouvellement
    • Et le déploiement via Key Vault + CSI Driver

Si comme dans ton cas, la majorité des applications sont internes :

👉 La solution recommandée : Azure Key Vault

Key Vault permet de :

  • Générer un certificat signé par une autorité d’entreprise,
  • Stocker le certificat et la clé privée de manière sécurisée,
  • Les exposer via le CSI Driver sans les injecter dans etcd.

Cert-Manager gère tout le cycle de vie (demande, validation, stockage, renouvellement).
En revanche, Azure Key Vault ne renouvelle automatiquement les certificats que si :

  • Tu utilises une CA intégrée (ex. DigiCert ou Entrust) configurée dans le Key Vault
  • Tu as défini un lifetimeAction avec renouvellement automatique
⚠️ Si ces conditions ne sont pas réunies, le renouvellement doit être déclenché manuellement ou automatisé via :
– un pipeline CI/CD,
– un outil de supervision (Zabbix, Prometheus),
– ou une tâche programmée (Azure Automation, Logic App…).

En sécurité, les certificats sont souvent les derniers oubliés… jusqu’au jour où tout tombe
Avec Cert-Manager, tu automatises tout le cycle de vie pour les zones publiques
Et avec Key Vault + CSI Driver, tu gardes le contrôle pour les environnements internes

🎯 Objectif : zéro surprise en prod.

La boucle est bouclée

BesoinSolutionLimite
Certificats publics avec DNS automatiséCert-Manager + AzureDNS⚠️ Zones publiques uniquement
Certificats pour services internesAzure Key Vault + CSI⚠️ Renouvellement à configurer manuellement (sauf CA intégrée)

📎 Pour aller plus loin (docs Microsoft) :