Le problème du secret zéro décrit une boucle sans fin : pour récupérer ses mots de passe et ses clés dans un coffre, une application a besoin d'un premier secret qui l'autorise à ouvrir ce coffre. Mais ce premier secret, il faut bien le protéger lui aussi, donc le mettre dans un autre coffre, qui demandera encore un secret, et ainsi de suite. La réponse moderne casse la boucle : au lieu de donner un secret à l'application, on lui donne une identité prouvable, vérifiée par la plateforme qui la fait tourner. Cette page explique le problème sans prérequis technique, puis les mauvaises et les bonnes réponses.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Le mot secret désigne ici toute donnée sensible qu'une application utilise pour se connecter à un service : un mot de passe de base de données, une clé d'accès à une API, un jeton. Concrètement, vous saurez :
- Décrire le problème du secret zéro et la boucle récursive qu'il crée.
- Distinguer les mauvaises réponses (secret en dur, variable d'environnement) des bonnes.
- Comprendre comment l'identité de charge et l'attestation brisent la boucle.
- Définir les termes clés du domaine : attestation, OIDC, SPIFFE, SVID.
- Relier ce problème à la page identité machine et workload identity et au modèle de menaces des secrets, qui traduisent ce concept en pratiques concrètes.
Qu'est-ce que le problème du secret zéro
Section intitulée « Qu'est-ce que le problème du secret zéro »Le problème du secret zéro (en anglais secret zero ou bootstrap trust problem, le problème d'amorçage de la confiance) part d'un constat simple. Les bonnes pratiques recommandent de ne jamais écrire un mot de passe directement dans le code d'une application. À la place, on stocke tous les secrets dans un coffre à secrets (un logiciel spécialisé qui garde les données sensibles chiffrées et ne les délivre qu'aux demandeurs autorisés). L'application interroge le coffre au démarrage pour récupérer ce dont elle a besoin.
Mais une question surgit aussitôt : comment l'application prouve-t-elle au coffre qu'elle a le droit d'accéder aux secrets ? Le coffre ne délivre rien à un inconnu. Il faut donc lui présenter un premier secret, un jeton d'accès ou un mot de passe. C'est ce premier secret qu'on appelle le secret zéro. On a déplacé le problème sans le résoudre : on ne stocke plus des dizaines de secrets dans le code, mais il en reste toujours un à placer quelque part.
La difficulté est récursive : elle se répète à l'infini. Le secret zéro doit être protégé. Où le mettre ? Si on le met en clair dans le code, on retrouve exactement le problème qu'on voulait éviter. Si on le range dans un second coffre, ce second coffre demandera lui aussi un secret pour s'ouvrir, un secret zéro numéro deux. On a construit une boucle sans fin : chaque secret protégé par un autre secret, qui doit lui-même être protégé.
L'analogie parlante est celle d'une clé de coffre-fort. Vous rangez vos objets précieux dans un coffre. Pour le sécuriser, vous cachez la clé de ce coffre. Mais où ? Dans un second coffre, plus petit. Sauf que ce second coffre a aussi une clé, qu'il faut cacher, dans un troisième coffre... À un moment, il y a forcément une première clé que personne ne protège vraiment, laissée sur le rebord de la fenêtre. C'est le maillon faible, et c'est exactement le secret zéro.
Les réponses possibles
Section intitulée « Les réponses possibles »Face à cette boucle, il existe des réponses commodes mais dangereuses, et des réponses solides qui la brisent vraiment. La différence tient à une idée : arrêter de transmettre un secret, et commencer à prouver une identité.
Les mauvaises réponses
Section intitulée « Les mauvaises réponses »La première mauvaise réponse est le secret en dur (en anglais hardcoded secret), c'est-à-dire écrit directement dans le code source. C'est la solution de facilité absolue. Le secret zéro se retrouve dans un fichier versionné, souvent poussé sur un dépôt Git, parfois public. N'importe qui ayant accès au code lit le secret. Pire, une fois dans l'historique Git, il y reste même après suppression, tant qu'on ne réécrit pas l'historique.
La deuxième mauvaise réponse est la variable d'environnement (une valeur injectée dans l'environnement du processus au lancement). C'est déjà mieux que le code en dur, car le secret ne vit plus dans le dépôt. Mais le problème se déplace encore : d'où vient cette variable ? Elle est souvent définie dans un fichier de configuration, un script de déploiement ou un gestionnaire de conteneurs, où le secret zéro réapparaît en clair. De plus, les variables d'environnement fuient facilement : elles apparaissent dans les journaux, les rapports d'erreur, les outils de diagnostic qui listent l'environnement d'un processus.
Le point commun de ces deux approches : le secret zéro est un secret statique, une valeur fixe qui ne change pas et qu'il faut poser quelque part. Le sujet des secrets figés est traité en détail dans secrets statiques ou dynamiques.
La bonne réponse : l'identité de charge par attestation
Section intitulée « La bonne réponse : l'identité de charge par attestation »La réponse moderne renverse le raisonnement. Plutôt que de donner un secret à l'application, on lui donne une identité de charge (en anglais workload identity : l'identité propre d'un programme qui tourne, distincte de l'identité d'un humain). L'application ne dit plus « voici mon mot de passe », elle dit « voici qui je suis, vérifiez-le auprès de la plateforme qui me fait tourner ».
Le mécanisme qui rend cela possible s'appelle l'attestation (en anglais attestation). Attester, c'est faire confirmer un fait par un tiers de confiance. Ici, la plateforme d'exécution (le cloud, l'orchestrateur de conteneurs comme Kubernetes) connaît l'application qu'elle fait tourner. Elle peut donc témoigner de son identité auprès du coffre. Le coffre ne fait plus confiance à un secret présenté par l'application, il fait confiance à la plateforme qui affirme « ce programme est bien celui qu'il prétend être ».
Deux standards structurent ce domaine. Le premier est OIDC (OpenID Connect), un protocole d'authentification très répandu. Dans ce cadre, la plateforme délivre à l'application un jeton OIDC de courte durée, signé cryptographiquement, qui prouve son identité. L'application présente ce jeton au coffre, qui vérifie la signature et accorde l'accès. Ce jeton n'est pas un secret à cacher : il est éphémère (il expire vite, en minutes) et lié à un contexte précis, donc inutile pour un attaquant qui le récupérerait trop tard.
Le second est SPIFFE (Secure Production Identity Framework For Everyone), un cadre ouvert qui donne à chaque charge de travail une identité vérifiable, indépendante du fournisseur cloud. Cette identité prend la forme d'un SVID (SPIFFE Verifiable Identity Document), un document d'identité vérifiable délivré et renouvelé automatiquement à l'application. Comme le jeton OIDC, le SVID est temporaire et attesté : il n'y a plus de secret figé à poser sur le rebord de la fenêtre.
Le mettre en oeuvre
Section intitulée « Le mettre en oeuvre »Ce concept ne reste pas théorique : il se met en place avec des outils concrets. La page dédiée identité machine et workload identity détaille comment une application obtient une identité vérifiable et l'utilise pour s'authentifier, sans jamais manipuler de secret zéro. C'est la lecture à suivre pour passer du principe à la pratique.
Côté coffre, le guide HashiCorp Vault montre comment un coffre concret accepte une identité attestée plutôt qu'un mot de passe fixe. Vault sait valider un jeton OIDC ou une identité de plateforme, puis délivrer des secrets à durée de vie limitée. Combiné à l'identité de charge, il ferme la boucle du secret zéro de bout en bout.
Enfin, le principe du moindre privilège reste indispensable : une identité, même solidement attestée, ne doit donner accès qu'aux secrets strictement nécessaires à l'application, et rien de plus. Une identité fiable qui ouvre tout le coffre reste un risque.
Pièges courants
Section intitulée « Pièges courants »Le premier piège est de croire le problème résolu par un coffre à secrets seul. Installer un coffre est une bonne chose, mais si l'application y accède avec un mot de passe fixe stocké dans sa configuration, le secret zéro est simplement caché, pas éliminé. Le coffre déplace le problème, il ne le règle pas mécaniquement.
Le deuxième piège est de traiter un jeton éphémère comme un secret durable. Un jeton OIDC ou un SVID tire sa sécurité de sa courte durée de vie et de son renouvellement automatique. Si une équipe le capture pour le réutiliser longtemps, le stocke dans un fichier ou le fige dans une variable, elle recrée exactement le secret statique qu'elle voulait supprimer.
Le troisième piège est de négliger la racine de confiance. L'identité de charge repose sur la plateforme qui atteste. Si cette plateforme est mal configurée, si n'importe quel conteneur peut réclamer n'importe quelle identité, l'attestation ne vaut rien. La sécurité du système entier se concentre alors sur la solidité de cette racine, qui devient le nouveau point critique à protéger.
Le dernier piège est d'oublier la révocation et l'audit. Passer à l'identité de charge ne dispense pas de savoir qui a accédé à quoi, ni de pouvoir couper l'accès d'une charge compromise. Une identité vérifiable mal tracée reste un angle mort en cas d'incident.
À retenir
Section intitulée « À retenir »-
Le secret zéro est le premier secret : celui qui permet à une application d'ouvrir le coffre où sont rangés tous les autres.
-
Le problème est récursif : protéger le secret zéro dans un autre coffre crée un nouveau secret zéro, à l'infini. Il y a toujours une première clé à cacher.
-
Le secret en dur et la variable d'environnement sont de fausses solutions : elles déplacent le secret statique sans casser la boucle.
-
L'attestation renverse le problème : l'application ne présente plus un secret, elle prouve son identité, confirmée par la plateforme qui la fait tourner.
-
OIDC et SPIFFE fournissent des identités éphémères : un jeton OIDC ou un SVID vérifiable remplace la clé figée par une preuve qui expire vite.
-
La racine de confiance devient le point critique : la plateforme qui atteste doit être solidement protégée, sinon toute la chaîne s'effondre.
-
Passez au socle : privilégier des identités courtes et éphémères de type OIDC répond à l'exigence SOCLE-SEC-GEN-5. Le modèle de menaces des secrets montre les attaques que ce choix neutralise.