Au quotidien
Secrets
Les identifiants qu’un serveur garde pour ses services, où ils vivent, et comment on en change un.
Un module qui a besoin d’un identifiant — un mot de passe de base, un jeton d’API, une clé de fournisseur — le laisse sur la machine qui s’en sert. Pas sur la plateforme, et pas dans l’app.
Où ils vivent
Dans un seul fichier, /etc/pupitre/env, lisible par root seul. L’agent tourne en root et le lit quand il le doit ; rien d’autre sur la machine ne le peut. Une valeur y arrive d’une seule façon : elle voyage sur l’entrée standard de la session SSH, sur la ligne que le protocole réserve aux secrets, donc elle ne fait jamais partie d’une requête qui pourrait être journalisée.
Comment il y arrive
Vous le tapez une fois, dans la configuration du module — à l’installation, ou plus tard. La valeur passe au processus principal de l’app et part directement sur cette ligne de secrets. Elle n’est pas gardée dans l’app, pas écrite dans un journal, et plus affichée ensuite.
Un champ secret peut aussi être généré pour vous. Ce qui est généré est écrit sur le serveur et jamais montré : vous le récupérez depuis la page du service, qui montre un identifiant à la fois et le copie sans l’imprimer nulle part.
Des comptes, pas des serveurs
Certains identifiants sont les mêmes sur toutes les machines : un jeton GitHub, un compte de service 1Password, une clé Neon, un jeton Cloudflare. Ceux-là se connectent une fois, comme un compte, dans les réglages de l’app ou au-dessus des questions du module. L’app les garde dans le trousseau de votre ordinateur, les vérifie à la seconde où vous les collez là où le fournisseur peut être interrogé, et remplit elle-même le champ du module à l’installation.
Rien ne change à la façon dont ils atteignent la machine. Le jeton voyage sur la ligne de secrets de l’installation comme les autres, et se range dans le même fichier réservé à root. Ce qui change, c’est que vous le tapez une fois plutôt qu’une fois par serveur — et qu’un module dont le compte n’est pas connecté est refusé avant la première étape, au lieu d’échouer sur la machine.
En changer un
Ouvrez le service, et appliquez de nouveau sa configuration. Le formulaire est celui du module, rempli de ce que l’agent a gardé de la dernière installation ; un secret laissé vide reste celui que le serveur détient, un secret retapé le remplace.
Passer par le module plutôt que par le fichier est ce qui rend le changement réel : un mot de passe de base vit à la fois dans le fichier et dans la base, et seul le module change les deux.
Ce que l’app ne fait jamais
Elle n’en garde pas de copie, elle n’en envoie pas à la plateforme, et elle n’en met pas dans un journal. La règle est la même que partout ailleurs dans Pupitre : un secret existe sur votre laptop le temps que vous le tapez, et sur votre serveur ensuite.