docs(openbao) : la métadonnée d'un secret_id ne dit pas si c'est un conteneur #39
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs/approle-metadata-does-not-say-container"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce que la page disait, et pourquoi c'est dangereux
Le README du rôle
openbaodécrit le dernier geste du démontage des coffres de nœuds : révoquer surca1les quatresecret_idde l'AppRoledn42-node-certqui appartenaient aux nœuds. Il affirmait qu'ils étaient « distinguables de ceux des conteneurs par leur métadonnée, écrite à l'amorçage ».Ils ne le sont pas. La métadonnée ne porte que
{"node": "fr-rbx1"}— rien sur la nature de l'hôte. Il y a huit accessors pour quatre nœuds, et chaque nœud apparaît donc deux fois :Suivre la phrase à la lettre revient à choisir au hasard entre les deux. Et la panne est silencieuse : le certificat en place reste valide, l'erreur n'apparaît qu'au renouvellement suivant, 90 jours plus tard, loin de sa cause.
Ce qui apparie réellement
La date de création côté
ca1et lemtimedu fichiersecret-iddu conteneur, à quelques secondes l'un de l'autre et dans le même ordre :ca1(création)mtimedu fichier)Les quatre autres datent du 07/08 entre 21:59 et 22:08, espacés de plusieurs minutes — l'amorçage manuel nœud par nœud, dix minutes après le merge de la #12. Ce sont eux, les nœuds.
⚠ La seule chronologie git n'aurait pas suffi à trancher : les
secret_iddu 09/08 sont antérieurs au commit qui pose le coffre en conteneur (263d98f, 23:30). Ils ont été émis pendant les essais, avant le merge. C'est lemtimesur les conteneurs qui fait la preuve, pas l'historique.Ce que la page gagne
ansible container_openbao -m raw -a "stat …")openbao-cert-agentsur un conteneur et vérifier qu'il obtient toujours un certificat. C'est ce qui ramène la détection de l'erreur de 90 jours à une minutecidr_listvide de cessecret_id, là où le cluster DN42 restreint. C'est ce qui a fait que le renumérotage des conteneurs des 13-14/08 n'a rien cassé côtéca1— commodité d'un côté, faiblesse de l'autre. Signalé comme une différence de posture entre les deux coffres qui n'a jamais été tranchée, pas corrigé ici.Portée
Documentation seule, aucun changement de comportement. Indépendante de la #38 : branchée sur
main, elle ne touche aucun fichier qu'elle modifie../.ci/lint.sh:OK: every available check passed.🤖 Generated with Claude Code
https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
Le README affirmait que les secret_id des nœuds étaient distinguables de ceux des conteneurs par leur métadonnée. Ils ne le sont pas : elle ne porte que `{"node": …}`, donc chaque nœud apparaît deux fois dans la liste des accessors. Une révocation faite sur cette phrase détruit un accessor sur deux au hasard, et la panne n'apparaît qu'au renouvellement suivant, 90 jours plus tard. Ce qui apparie réellement est la date de création côté ca1 et le mtime du fichier secret-id du conteneur, à quelques secondes l'un de l'autre et dans le même ordre. La commande de tri et le contrôle d'après-destruction remplacent la phrase fausse. Au passage : le cidr_list de ces secret_id est vide, là où le cluster DN42 restreint. C'est ce qui a fait que le renumérotage des conteneurs n'a rien cassé côté ca1 — noté comme une différence de posture non tranchée, pas corrigé ici. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9