Cycle des identifiants et exécution ont besoin de responsables distincts

Un gestionnaire de secrets doit décider quel identifiant existe, quand il expire et comment il cesse d'être valide. Une passerelle locale doit décider si ce processus peut exécuter cette action maintenant, réaliser l'action sans remettre l'identifiant au processus et consigner ce qui s'est passé. Réunir ces deux tâches paraît plus simple jusqu'à ce qu'une première rotation, révocation ou enquête demande quel composant était réellement responsable.

La frontière dépend de la possession au moment de l'utilisation, pas du lieu de stockage. HashiCorp Vault ou un flux adossé à 1Password peut rester l'autorité du cycle de vie pendant qu'une passerelle contrôle l'exécution, mais seulement si le transfert conserve l'état du cycle et l'identité sans transformer la passerelle en cache non suivi. Si la passerelle copie une valeur, oublie son bail et continue à l'utiliser, le schéma compte deux blocs, mais le système compte deux gestionnaires de secrets.

Ce modèle justifie le raccordement supplémentaire lorsque des agents autonomes peuvent atteindre des API de production ou des cibles SSH. Ces agents ont besoin d'actions délimitées et d'un contrôle humain. Ils n'ont pas besoin d'une autre façon de lire les identifiants.

La frontière précède l'action authentifiée

Le système de cycle de vie possède la création, la rotation, l'expiration et la révocation des identifiants; la passerelle d'exécution possède la libération de chaque action authentifiée. Cette phrase constitue le test d'architecture. Chaque champ, cache, nouvelle tentative et entrée de journal doit avoir un seul côté qui en répond.

La responsabilité du cycle de vie va au-delà de la conservation d'une chaîne chiffrée. Pour un compte de base de données dynamique, elle comprend le rôle qui crée le compte, l'ID du bail, le TTL, les règles de renouvellement et l'opération qui supprime ou désactive le compte. Pour un jeton API statique, elle comprend l'émetteur en amont, la génération actuelle, l'heure d'activation, une éventuelle période de chevauchement et la preuve que l'ancienne génération ne fonctionne plus. Un gestionnaire de mots de passe peut conserver l'enregistrement de référence, mais l'API distante décide toujours si elle accepte le jeton.

La responsabilité d'exécution commence lorsqu'un appelant demande un effet tel que GET /billing/invoices, POST /deployments ou une commande SSH sur un hôte nommé. La passerelle authentifie l'appelant, vérifie l'approbation locale, résout l'identifiant autorisé, l'injecte dans le protocole sortant et ne renvoie que le résultat. Elle ne doit pas proposer une action générale read secret à l'agent. Cela ramènerait l'exécution à la distribution de secrets.

Une interface nette nomme donc une action et une référence d'identifiant, pas une valeur d'identifiant. Elle indique aussi la génération attendue afin qu'une demande retardée ne franchisse pas silencieusement une rotation. Une enveloppe de requête utile ressemble à ceci:

{
  "action_id": "01J...",
  "credential_ref": "vault:database/creds/agent-readonly",
  "expected_generation": "lease:database/creds/agent-readonly/2f6a...",
  "purpose": "read migration status",
  "target": "db-admin.internal",
  "caller": {
    "session_id": "sess_7f2...",
    "process_authority": "signed:TEAMID.example.agent"
  }
}

La passerelle peut obtenir la valeur sous-jacente, car un composant doit placer des octets dans un en-tête Authorization ou une négociation SSH. La contrainte est qu'elle obtienne cette valeur dans le chemin d'exécution de confiance, qu'elle l'écarte des arguments, variables d'environnement, fichiers, résultats d'outil et textes d'erreur visibles par l'agent, puis qu'elle la supprime selon une règle de cache documentée. L'absence de secret pour l'agent ne veut pas dire qu'aucun composant ne manipule jamais de texte en clair.

L'autorité du cycle crée et retire les identifiants

Utilisez Vault comme responsable du cycle de vie lorsque son moteur de secrets peut créer et révoquer l'identifiant dans le système cible. Utilisez un flux adossé à 1Password comme responsable d'un identifiant statique seulement si ce flux met aussi l'émetteur à jour, consigne la nouvelle génération et retire l'ancienne. Conserver uniquement la dernière valeur relève de la gestion d'inventaire, pas de la rotation.

La documentation de HashiCorp sur les baux Vault rend le contrat particulièrement explicite. Chaque secret dynamique reçoit un bail avec une durée et un indicateur de renouvellement. Vault promet que les données restent valides pendant cette durée, mais le consommateur ne peut plus supposer que l'identifiant fonctionne après l'expiration. La révocation d'un bail invalide le secret et empêche son renouvellement; pour les moteurs compatibles, Vault effectue aussi le nettoyage sous-jacent, par exemple en supprimant un identifiant cloud généré ou un utilisateur de base de données.

Ce comportement fait de Vault le responsable évident des identifiants dynamiques pris en charge. La passerelle doit demander ou recevoir un bail, observer le TTL renvoyé et cesser de l'utiliser avant sa fin. Elle ne doit jamais inventer une durée locale supérieure. HashiCorp avertit également que l'incrément demandé lors d'un renouvellement reste indicatif et que le client doit examiner la réponse. Une passerelle qui demande une heure supplémentaire et suppose l'avoir obtenue a déjà rompu la responsabilité du cycle.

Le moteur KV de Vault est différent. La documentation de Vault précise que KV n'émet pas de baux, même si une réponse affiche une durée. Placer un jeton API dans KV ne le rend pas dynamique, et supprimer une ancienne version KV ne révoque pas forcément le jeton chez son émetteur. Le flux de rotation doit appeler le fournisseur, vérifier le remplacement, mettre à jour l'enregistrement de référence et désactiver l'ancien jeton.

La même réserve vaut pour 1Password. Sa documentation CLI décrit les références de secrets et des commandes telles que op run, op read et op inject. Ces mécanismes récupèrent un secret stocké pendant l'exécution. Ils ne font pas, à eux seuls, tourner une clé API tierce générique auprès de son émetteur. Une équipe peut garder l'enregistrement de référence dans 1Password, mais l'automatisation qui l'entoure doit prendre en charge la mise à jour distante et le retrait.

N'attribuez pas le cycle de vie selon la catégorie du fournisseur. Attribuez-le à partir du contrôle démontré sur l'émetteur et d'un changement de génération observable.

Un transfert sûr passe une référence et un bail

La passerelle a besoin d'une référence qu'elle peut résoudre, d'une limite de validité et d'un chemin de révocation. Une référence seule résout le nom, mais perd la dimension temporelle. Une date d'expiration seule perd l'autorité capable de révoquer. Une valeur secrète seule perd les deux.

Pour les secrets dynamiques Vault, l'identifiant de génération naturel est l'ID du bail. La réponse à vault read database/creds/my-role contient lease_id, lease_duration, lease_renewable, username et password. La passerelle doit lier les octets de l'identifiant et ces métadonnées dans un même objet. Elle ne doit pas stocker le mot de passe dans un cache et le bail dans un autre susceptible de dériver.

Pour un enregistrement statique dans 1Password, créez un marqueur de génération immuable dans le flux de rotation. Il peut s'agir d'un identifiant de version exposé par l'intégration choisie ou d'un ID d'événement de rotation conservé avec la référence. N'utilisez pas un nom mutable tel que prod-api-key comme génération. Le nom indique où résoudre la référence, mais ne prouve pas la valeur reçue.

Le contrat de transfert doit inclure ces propriétés:

• credential_ref identifie la source sans contenir de matière secrète.
• generation change chaque fois que l'identifiant utilisable change.
• not_after donne à la passerelle une heure d'arrêt locale ferme lorsqu'elle existe.
• revocation_ref indique aux outils d'intervention quel objet révoquer ou retirer.
• issued_for lie l'identifiant au rôle, à la cible et à l'environnement prévus.

Une réponse de passerelle doit reprendre les éléments non secrets pour que l'appelant et la chaîne d'audit puissent corréler un effet sans connaître l'identifiant:

{
  "action_id": "01J...",
  "status": 200,
  "credential_ref": "vault:database/creds/agent-readonly",
  "generation": "lease:database/creds/agent-readonly/2f6a...",
  "executed_at": "2026-07-27T14:03:12Z",
  "result_digest": "sha256:9b0..."
}

Ce contrat révèle aussi une difficulté: une passerelle locale a besoin de sa propre identité de machine pour interroger le système de cycle de vie. Cet identifiant initial possède lui aussi un cycle. Un jeton Vault doit avoir une politique étroite et son propre TTL ou comportement de renouvellement. Un jeton de compte de service 1Password ne doit atteindre que les coffres nécessaires. Cacher le jeton initial dans un fichier de réglages local déplace simplement le problème d'un niveau.

L'expiration doit l'emporter sur les caches et les reprises

L'expiration survit au transfert uniquement si chaque chemin d'exécution compare l'heure actuelle à la limite renvoyée par l'autorité du cycle de vie. La passerelle doit refuser une nouvelle action lorsque la durée restante ne couvre pas la résolution, l'approbation, la connexion, l'exécution et une petite marge d'horloge.

Supposons que Vault émette un identifiant de base de données pour dix minutes. Un agent lance un export à la neuvième minute, l'utilisateur passe quarante secondes à lire la carte d'approbation, puis la passerelle réessaie deux fois après une coupure réseau. Un cache qui n'a vérifié le TTL qu'au moment de la récupération peut lancer la dernière reprise après l'expiration. La cible renvoie alors une erreur d'authentification, mais le journal peut la classer à tort comme une panne réseau ou un refus humain.

Fixez une seule fois l'échéance utilisable à partir des métadonnées de référence:

usable_until = min(authority_not_after, fetched_at + local_cache_cap)
latest_start = usable_until - approval_budget - connect_budget - clock_margin

Ces budgets sont des choix d'exploitation, pas des prolongations de la durée de l'identifiant. Si now dépasse latest_start, récupérez une nouvelle génération et affichez une nouvelle approbation si l'action approuvée change de manière significative. Ne renouvelez jamais un bail Vault pour sauver une requête qui a attendu dans une file locale. Le renouvellement appartient au cycle de vie et peut agrandir la période d'exposition.

Les reprises exigent la même discipline. Une reprise peut réutiliser un identifiant seulement si la génération correspond encore, si l'identifiant se trouve dans sa durée utile et si l'opération distante peut être répétée sans risque. L'idempotence HTTP et la validité de l'identifiant sont deux vérifications distinctes. Un jeton valide ne rend pas un doublon de POST inoffensif.

Pour les identifiants statiques sans expiration fournie par l'émetteur, utilisez une limite locale de cache pour réduire la durée des anciennes copies, mais appelez-la politique de cache et non expiration. Le flux de cycle de vie a toujours besoin d'une notification de génération ou d'une nouvelle résolution forcée après la rotation. Sinon, la passerelle peut conserver un ancien jeton encore valide pendant le chevauchement et donner l'impression que le test de retrait a réussi jusqu'à ce que le fournisseur le désactive enfin.

La révocation est un événement de bout en bout

La révocation fonctionne seulement lorsque l'autorité du cycle désactive l'identifiant chez l'émetteur et que la passerelle arrête toute utilisation future de la génération en cache. Nettoyer un seul côté reste incomplet.

Vault donne aux opérateurs un mécanisme concret. vault lease revoke invalide un bail et la révocation par préfixe peut invalider les baux sous un chemin. La documentation des commandes HashiCorp distingue aussi la révocation normale de la suppression forcée. Une suppression forcée peut faire oublier un bail à Vault même si le moteur de secrets n'a pas réussi à le révoquer, laissant Vault désynchronisé de la cible. Traitez cet avertissement comme un incident, pas comme un message de nettoyage réussi.

Une passerelle locale doit recevoir un signal de révocation lorsque le système de cycle peut en envoyer un, mais elle a aussi besoin d'une défense qui interroge l'état actuel. Avant une utilisation sensible, elle peut revalider la génération ou la résoudre à nouveau. Pour de courts baux Vault, un TTL strict et un cache bref peuvent suffire. Pour un jeton API statique, le coordinateur de rotation doit invalider le cache de la passerelle lors du basculement, puis tester directement le jeton retiré sur un point de terminaison sans effet.

Les actions déjà en cours nécessitent une règle explicite. La révocation peut bloquer de manière fiable les actions qui n'ont pas commencé. Elle ne peut pas forcément annuler une requête déjà acceptée par une API distante, une transaction déjà validée ou une commande SSH déjà remise au shell. La passerelle doit marquer l'état authorized, dispatched, acknowledged ou unknown, plutôt que d'affirmer que la révocation a effacé l'effet.

Testez le chemin complet en conservant l'ancienne génération dans un outil contrôlé:

1. Exécutez une lecture sans effet via la passerelle et notez la génération.
2. Révoquez le bail ou faites tourner l'identifiant statique et désactivez-le chez l'émetteur.
3. Tentez la même action avec un cache de passerelle encore chaud.
4. Tentez une utilisation directe de l'identifiant retiré depuis l'outil.
5. Confirmez les deux échecs et reliez-les aux journaux du cycle et de l'exécution.

Si l'étape trois réussit, la passerelle a ignoré la révocation. Si l'étape quatre réussit, le flux de cycle de vie n'a pas révoqué chez l'émetteur. Si les deux échouent mais que les journaux ne désignent pas la même génération, l'équipe d'intervention ne peut toujours pas prouver ce qui s'est passé.

L'attribution exige l'identité de l'émetteur et de l'appelant

Les journaux du cycle indiquent qui a créé, renouvelé, fait tourner ou révoqué un identifiant. Les journaux de la passerelle indiquent quel processus local a demandé quelle action, qui l'a approuvée, quelle cible l'a reçue et quel résultat est revenu. Aucun ne remplace l'autre.

Les identifiants dynamiques améliorent l'attribution chez l'émetteur lorsque chaque bail produit une identité distante distincte. La documentation HashiCorp du moteur de secrets de bases de données indique que les noms d'utilisateur générés et uniques permettent de rattacher un accès à une instance précise de service. C'est utile, mais le nom d'utilisateur de base de données identifie encore l'identité louée de la passerelle, pas forcément le processus agent qui a demandé la requête.

La passerelle a donc besoin d'une identité de session stable et d'une identité de processus digne de confiance. Un PID seul est faible, car les systèmes d'exploitation réutilisent les PID et les processus peuvent lancer des enfants. Consignez l'identité de l'exécutable disponible sur la plateforme, son autorité de signature le cas échéant, le processus parent, le début et la fin de session et un ID de session impossible à deviner. Liez chaque enregistrement d'action à cette session.

Le champ de jointure est la génération de l'identifiant. Placez l'ID de bail Vault ou l'ID d'événement de rotation statique dans le journal du cycle et dans celui de l'action. Consignez aussi l'ID de requête distante lorsque l'API en renvoie un. Lors d'un incident, les enquêteurs doivent pouvoir suivre cette chaîne:

agent session -> gateway action -> credential generation -> issuer event -> remote request

Ne placez ni valeurs secrètes, ni en-têtes Authorization, ni clés privées, ni blocs d'environnement résolus dans ces journaux. Le masquage après journalisation manque de fiabilité, car les exceptions, vidages de débogage et exportateurs de traces peuvent copier les données avant. Construisez des enregistrements structurés à partir d'une liste de champs sûrs.

L'attribution échoue aussi lorsque toutes les actions partagent un compte de service de longue durée et qu'aucun journal de passerelle ne survit. La rotation réduit la durée de ce compte, mais n'identifie pas l'appelant. À l'inverse, des journaux de processus parfaits ne prouvent pas quelle génération a atteint la cible si la passerelle omet le bail ou la version. Conservez les deux dimensions.

L'injection dans l'environnement franchit la frontière

Un flux qui injecte un secret dans l'environnement d'un agent lui en donne la possession; la passerelle ne contrôle donc plus chaque utilisation. Cette distinction compte particulièrement pour les modèles CLI de 1Password, car la facilité de récupération peut ressembler à un contrôle de l'exécution.

La documentation 1Password indique que op run lance un sous-processus avec des secrets fournis sous forme de variables d'environnement. C'est parfois un moyen raisonnable de garder le texte en clair hors d'un fichier .env versionné, mais le processus enfant peut lire la variable, l'afficher, la transmettre à un autre processus ou l'utiliser pour une demande non approuvée. op inject résout des références dans un flux de configuration et op read renvoie une valeur résolue à l'appelant. Aucun de ces chemins n'équivaut à une passerelle qui garde le secret hors de portée de l'agent.

Pour des scripts conduits par des humains qui ont besoin du comportement complet d'un SDK natif, l'injection d'environnement peut convenir. Pour un agent autonome dont les actions réseau et SSH exigent un contrôle à chaque utilisation, elle détruit la frontière recherchée. Donnez l'identité de récupération restreinte à la passerelle et exposez à l'agent des outils orientés action.

L'identifiant initial mérite toujours une analyse. 1Password recommande les comptes de service pour limiter les droits et permet de restreindre leur accès à certains coffres. Cela réduit ce que la passerelle peut récupérer. Cela ne limite pas ce qu'elle peut faire après récupération; sa surface d'actions, ses approbations et la validation des cibles sortantes restent donc nécessaires.

Évitez un contournement courant: résoudre le secret dans un wrapper, appeler la passerelle avec l'identifiant comme paramètre, puis promettre qu'elle le masquera. L'agent ou le wrapper a déjà possédé la valeur, l'historique du shell et l'inspection des processus peuvent l'exposer, et la passerelle ne peut pas prouver l'absence de seconde utilisation. Passez la référence à travers la frontière et résolvez-la dans le composant qui exécute.

L'approbation ne dépend pas de la rotation

Un identifiant tout juste renouvelé peut encore autoriser une mauvaise action, et une action soigneusement approuvée peut encore utiliser un identifiant périmé. La rotation et l'approbation réduisent des risques différents, aucune ne doit donc remplacer l'autre en silence.

L'autorité du cycle répond: «Cette génération est-elle valide?» La passerelle répond: «Cet appelant peut-il produire cet effet maintenant?» Le service distant répond: «Cette identité authentifiée a-t-elle l'autorisation?» Gardez les trois réponses visibles. Une carte d'approbation verte ne doit pas suggérer que l'identifiant est à jour si la passerelle ne l'a pas vérifié. Un bail actuel ne doit pas contourner l'approbation humaine exigée pour un appel destructeur.

La réutilisation d'une approbation a besoin d'une portée définie. Si la passerelle approuve une session d'agent, liez cette approbation à la session du processus et terminez-la lorsque le processus s'arrête ou que l'utilisateur la révoque. Si un identifiant exige une approbation à chaque appel, la rotation doit conserver cette exigence pour la nouvelle génération. Une nouvelle valeur ne doit pas ramener un identifiant sensible à un réglage par défaut moins strict.

Le texte d'approbation doit décrire l'action, la cible et l'appelant, pas le secret. «Autoriser le processus signé X à exécuter POST /deployments en production» donne une information exploitable. «Autoriser l'utilisation de la clé API prod-3» force l'utilisateur à déduire l'intention à partir d'un nom d'inventaire et l'habitue à approuver des demandes opaques.

Sallyport met en œuvre cette moitié d'exécution pour les actions HTTP API et SSH sur macOS: les agents se connectent par son shim MCP, les identifiants restent dans son coffre chiffré au sein du processus et l'application exécute l'action. Ses contrôles fixes séparent le coffre verrouillé, l'approbation de la session de processus et l'approbation facultative à chaque utilisation; ce modèle ne supprime pas le besoin d'une autorité externe du cycle lorsqu'un autre système crée ou fait tourner l'identifiant.

Deux rotations créent deux autorités apparentes

Ne laissez pas le système de cycle de vie et la passerelle faire tourner le même identifiant indépendamment. Certaines équipes appellent cela de la défense en profondeur, mais deux auteurs créent des générations ambiguës, des retours arrière incertains et des courses de révocation.

Imaginez un fournisseur statique qui permet deux clés API actives. Le flux 1Password crée la clé B, la teste et met à jour l'élément de référence pendant que la clé A reste active durant un bref basculement. Au même moment, le planificateur local de la passerelle crée la clé C parce que sa copie de A a atteint un âge configuré. Certains processus résolvent B, le cache chaud conserve A et la passerelle commence à utiliser C. Désactiver A ne prouve presque rien, car personne ne sait si B ou C doit survivre.

Un seul coordinateur doit posséder la machine d'états de rotation. Pour un secret dynamique Vault, Vault fournit déjà cette coordination par ses rôles et ses baux; la passerelle consomme les baux et ne fait pas tourner le compte distant. Pour un enregistrement statique géré avec 1Password, la tâche de rotation peut coordonner le fournisseur et l'élément stocké; la passerelle observe les changements de génération et invalide son cache. Le chiffrement local de la passerelle protège une copie stockée, mais rechiffrer le stockage ne constitue pas une rotation chez l'émetteur.

Une rotation statique exploitable possède des états explicites plutôt qu'un unique indicateur rotated:

prepared -> activated -> distributed -> old_disabled -> verified
                |             |
                +-> rollback <-+

prepared signifie que l'émetteur a créé une génération candidate. activated signifie qu'une requête authentifiée sans effet a réussi avec elle. distributed signifie que la référence officielle se résout vers la candidate et que les passerelles reconnaissent la nouvelle génération. old_disabled signifie que l'émetteur refuse la précédente. verified signifie qu'une passerelle au cache chaud et un outil direct échouent avec l'ancienne valeur. Ne gardez le retour arrière possible que pendant que la génération précédente reste volontairement active.

La passerelle doit recevoir des changements d'état contenant des références et des ID de génération, jamais les deux valeurs secrètes. Un événement d'invalidation peut nommer credential_ref, old_generation, new_generation et effective_at. À sa réception, la passerelle supprime l'ancienne entrée de cache, annule les actions en attente qui lui sont liées et résout de nouveau au démarrage de la prochaine action approuvée. Si l'événement n'arrive jamais, la limite de cache et la vérification de génération doivent tout de même converger vers la valeur de référence.

Un retour arrière exige la même rigueur. Repointer un élément 1Password vers la clé A ne fonctionne pas si le fournisseur a désactivé A. Réémettre une nouvelle valeur sous l'ancien nom visible ne restaure pas non plus l'ancienne génération. Le coordinateur doit créer ou réactiver uniquement ce que le fournisseur prend en charge, attribuer un nouvel ID de génération et recommencer les étapes normales de distribution et de vérification.

Gardez le registre des responsabilités assez court pour le lire pendant un incident. Pour chaque référence d'identifiant, nommez un coordinateur de rotation, un émetteur, une politique de cache de passerelle, une commande de révocation et une personne ou un service autorisé à lancer un retrait d'urgence. Si deux lignes affirment pouvoir créer la prochaine génération, arrêtez. Ce n'est pas une redondance, mais une course qui manipule de la matière secrète.

Testez la jointure plutôt que chaque bloc

Un test Vault réussi et un test de passerelle réussi ne prouvent pas que leur transfert fonctionne. Testez à la frontière les caches anciens, les générations qui se chevauchent, les approbations retardées, les révocations en échec, les redémarrages de processus et les champs de jointure manquants.

Utilisez une identité cible jetable et exécutez cette matrice d'acceptation avant la production:

Exécutez la matrice sur les mêmes chemins que les agents utiliseront. Un simulacre qui renvoie 401 sur demande ne révèle pas si un véritable module de base de données a supprimé un utilisateur, si un fournisseur accepte des clés en chevauchement ou si une connexion SSH reste active après la révocation de l'identifiant.

Fixez des critères de réussite explicites. Aucune action ne commence après not_after. Une génération révoquée ou retirée échoue à travers un cache chaud. Chaque journal d'exécution se joint à une génération du cycle sans matière secrète. L'échec de révocation chez l'émetteur interdit de déclarer le retrait réussi. Un journal d'approbation identifie une session de processus et expire selon le contrôle configuré.

La frontière remplit son rôle lorsque les pannes restent locales. Vault ou le flux de rotation 1Password peut remplacer les identifiants sans apprendre les valeurs secrètes à l'agent. La passerelle peut modifier son comportement d'approbation sans devenir l'émetteur. L'équipe d'intervention peut révoquer une génération, arrêter une session et voir quels effets distants ont peut-être déjà eu lieu. Si votre test de jointure ne prouve pas ces trois opérations indépendamment, corrigez le contrat avant d'ajouter un autre système de secrets.