Publié le 25 septembre 2026 à 09:00 · Publication originale
Une adresse IP ne suffit pas. Un conteneur peut disparaître puis renaître ailleurs; une charge de travail peut changer de machine.
SPIFFE a été conçu pour donner à ces logiciels une identité cryptographique indépendante de leur emplacement.
Une charge de travail reçoit par exemple l'identifiant:
spiffe://https://lnkd.in/ed9CE2XM
Cette identité peut être portée par un certificat X.509 de courte durée, un SVID. Deux services peuvent alors établir une connexion mTLS et vérifier l'identité de l'autre.
Reste le problème décisif: comment remettre ce premier certificat au bon processus sans lui demander un mot de passe qu'il faudrait déjà savoir protéger?
SPIRE, l'implémentation open source de SPIFFE, répond par l'attestation. Lorsqu'un processus appelle localement la Workload API, l'agent peut examiner des propriétés fournies par l'environnement: UID Unix, compte de service et namespace Kubernetes, image de conteneur ou autres sélecteurs configurés. Si elles correspondent à une identité enregistrée, le processus reçoit le SVID auquel il a droit.
L'identité n'est donc plus nécessairement un secret statique copié dans un fichier. Elle peut être attribuée à l'exécution et renouvelée automatiquement.
ULTRA®
La subtilité de la Workload API est que le processus qui l'appelle n'a pas besoin de présenter lui-même un secret d'authentification. Sur Unix, SPIRE peut utiliser les métadonnées du noyau liées à la connexion locale pour déterminer qui appelle.
On évite ainsi le problème circulaire du secret nécessaire pour obtenir le secret.
Pour un agent autonome, cela ne suffit pourtant pas. Prouver cryptographiquement "je suis refund-agent" ne signifie pas encore "je peux rembourser 200.000 euros".
SPIFFE établit l'identité. La politique d'autorisation décide ce que cette identité peut faire.
#VOCEASSOCIATION #IA #Cybersecurite #SPIFFE