Cryptographic Posture Management — découvrez, notez & remédiez tout votre patrimoine cryptographique
Autorité de certification souveraine pour l'émission et la gestion de certificats à l'échelle de l'entreprise
Gestion du cycle de vie des certificats : découverte, gouvernance et automatisation
Domain Control Validation agnostique des DNS, prêt pour les certificats TLS de 47 jours
Les agents IA et les workloads cloud créent des identités plus vite qu'aucun processus humain ne peut suivre. SPIFFE et SPIRE sont faits pour cette vitesse — mais par défaut, un serveur SPIRE signe depuis une AC auto-signée, invisible pour votre équipe PKI. Ce guide explique la faille que SPIRE laisse ouverte et comment ancrer son AC de signature à une racine d'entreprise gouvernée et souveraine transforme un îlot de confiance en partie intégrante de votre patrimoine.
L'identité agentique est le problème de donner aux acteurs non humains — agents IA, workloads et services — des identités qu'ils peuvent prouver, à une vitesse et un volume qu'aucun processus par ticket ne peut égaler. SPIFFE définit le format d'identité (le SPIFFE ID, porté par un justificatif de courte durée appelé SVID) et SPIRE en est l'implémentation de référence, attestant chaque workload et émettant son SVID X.509 à la vitesse machine.
SPIRE excelle dans l'émission massive et éphémère. Ce qu'il ne résout pas, c'est la gouvernance : par défaut, son AC de signature est un fichier auto-signé sur disque, hors de toute politique, de tout audit et de tout contrôle de cycle de vie qu'une organisation a construits. Ce guide couvre la faille que cela laisse, et le schéma qui la referme — ancrer l'AC de signature du serveur SPIRE à une racine d'entreprise gouvernée et souveraine via un plugin UpstreamAuthority, pour que SPIRE garde sa vitesse tandis que le domaine de confiance devient partie intégrante du patrimoine géré.
Les plus récents utilisateurs de la plupart des systèmes d'entreprise ne sont pas des personnes. Chaque agent IA, workload et service a besoin de sa propre identité pour s'authentifier, chiffrer et rendre des comptes, et une seule application peut en engendrer des milliers — des identités qui vivent quelques minutes, pas des années. Les émettre par ticket, tableur ou portail n'est pas lent ; c'est impossible. La question n'est plus de savoir s'il faut automatiser l'identité des workloads, mais qui ancre et gouverne le système qui s'en charge.
SPIFFE et SPIRE répondent très bien à la moitié « émission » de cette question. Ce guide traite de l'autre moitié — la gouvernance — et de la faille précise qu'un déploiement SPIRE standard laisse au sommet de sa chaîne de confiance.
Le standard ouvert de l'identité des workloads est volontairement minimaliste. Il définit un format d'identité et une manière de le distribuer, et laisse les questions opérationnelles difficiles — attestation, exploitation de l'AC, révocation — à l'implémentation.
Définit un format d'identité universel pour les workloads : le SPIFFE ID, porté par un justificatif de courte durée et automatiquement renouvelé appelé SVID.
L'implémentation de référence, s'exécutant dans votre infrastructure. Il atteste chaque workload — est-ce vraiment le service de facturation, sur ce nœud ? — et émet son SVID X.509 sur place, à la vitesse machine, sans humain dans la boucle.
SPIRE excelle dans l'émission massive et éphémère. C'est précisément le travail qu'un CLM ne doit pas tenter de faire certificat par certificat : des centaines de milliers de certificats éphémères ont leur place dans le mesh, pas dans une console de gestion.
SPIRE émet magnifiquement les SVID. La question à laquelle il ne répond pas seul est celle de ce vers quoi ces SVID remontent en définitive.
Chaque SVID remonte à l'AC de signature du serveur SPIRE. Par défaut, cette AC est un fichier plat sur disque : auto-signée, invisible pour l'équipe PKI, hors de toute politique, de tout audit et de tout contrôle de cycle de vie que l'organisation a construits. Une AC de signature non gouvernée, c'est un domaine de confiance non gouverné — pas de racine d'entreprise, pas de politique de révocation, pas de preuve de conformité, et un îlot de confiance coupé du reste du patrimoine. La réponse n'est pas de ralentir SPIRE ; c'est de l'ancrer correctement.
Le schéma utilise le propre point d'extension de SPIRE. Un plugin UpstreamAuthority permet au serveur SPIRE d'obtenir son AC de signature auprès d'une autorité externe au lieu d'en générer une lui-même, pour que le domaine de confiance s'ancre à une racine que l'organisation possède.
La répartition des rôles est tout l'enjeu : SPIRE gère les cent mille certificats qui vivent une heure ; le CLM gouverne celui qui les rend tous dignes de confiance.
Un binaire à côté du serveur SPIRE, un bloc de configuration : l'adresse du CLM, une clé API ou un certificat mTLS, et le profil d'émission à utiliser. Le bloc de config SPIRE est littéralement une entrée `UpstreamAuthority "horizon"`.
SPIRE demande son AC de signature via le plugin ; le CLM l'émet depuis un profil dédié, chaînée à l'AC d'entreprise, sur site. Tout le domaine de confiance SPIFFE s'ancre désormais à une racine que l'organisation possède, avec une AC souveraine derrière.
Les intermédiaires SPIRE apparaissent dans le CLM, étiquetés avec leur domaine de confiance et leur rôle — règles d'émission par profil, politiques de cycle de vie, journal d'audit, rotation et révocation — aux côtés de tous les autres certificats du patrimoine. Les garde-fous incluent la liste blanche de domaines de confiance et la révocation optionnelle de l'intermédiaire précédent à chaque rotation.
Ancrer n'est pas qu'une architecture plus propre — c'est ce qui rend un déploiement d'identité agentique défendable devant un auditeur et durable dans le temps.
Le plugin couvre les SVID X.509 — le versant certificat de SPIFFE — et se connecte avec une clé API ou un certificat client mTLS, les secrets étant référencés par chemin ou par coffre-fort plutôt qu'en clair. C'est un ajout prêt à déposer dans un déploiement SPIRE existant : SPIRE continue d'émettre les SVID à la vitesse machine, et sa racine de confiance cesse d'être un îlot.
Le domaine de confiance se chaîne à une pile AC d'entreprise que vous contrôlez, sur votre infrastructure, pas à un fichier dans un pod.
Règles de profil, événements d'audit et historique de cycle de vie donnent aux auditeurs NIS2 et DORA la traçabilité que SPIRE seul ne peut pas produire.
Les intermédiaires de workloads vivent à côté de vos certificats TLS, de signature de code et utilisateurs : même inventaire, même notation, mêmes tableaux de bord.
Ancrez le déploiement SPIFFE à une hiérarchie d'AC capable de migrer vers les algorithmes hybrides et post-quantiques sans réarchitecturer le mesh.
