Stocker des secrets pour des scripts non supervisés : credentials systemd, DPAPI, trousseau macOS — et ce qu'il faut éviter

Objectif

Fournir à un script ou à un service non supervisé le secret dont il a besoin à l'exécution, sans l'exposer dans l'environnement d'autres processus, dans une liste de processus ni dans un fichier lisible par tous.

Prérequis

systemd 247+ pour LoadCredential=, 250+ pour systemd-creds et LoadCredentialEncrypted= (le chiffrement repose sur une clé dérivée du TPM2, sur la clé d'hôte /var/lib/systemd/credential.secret, ou sur les deux ; un TPM n'est donc pas strictement requis) ; PowerShell 5.1+ pour Export-Clixml, ou le module Microsoft.PowerShell.SecretManagement pour une abstraction plus complète d'un coffre de secrets ; macOS avec l'outil en ligne de commande security (intégré).

Étapes

1. Linux/systemd : en root, exécuter systemd-creds encrypt --name=mysecret plaintext.txt /path/mysecret.cred, puis supprimer plaintext.txt et référencer le fichier dans [Service] avec LoadCredentialEncrypted=mysecret:/path/mysecret.cred. Le nom intégré doit correspondre à l'identifiant du credential ; sans --name=, il est déduit du nom du fichier de sortie. Le service lit la valeur déchiffrée dans $CREDENTIALS_DIRECTORY/mysecret, une copie en lecture seule accessible uniquement au service (compatible avec DynamicUser=), plutôt que dans une variable d'environnement héritée par tous les processus enfants.
2. Windows : Get-Credential | Export-Clixml -Path secret.xml sérialise un objet credential ; la documentation de Microsoft indique que cela repose sur la Windows Data Protection API (DPAPI) : le fichier obtenu ne peut être déchiffré que par le même compte utilisateur, sur la machine qui l'a créé. Le copier vers un autre hôte ou un autre utilisateur le rend inutilisable, il faut donc le créer en s'exécutant sous le compte qui le lira. Cela ne vaut que sous Windows : PowerShell sous Linux/macOS écrit le mot de passe simplement encodé, non chiffré. Import-Clixml -Path secret.xml le relit dans le script. Pour des secrets nommés, Microsoft.PowerShell.SecretManagement nécessite une extension de coffre telle que Microsoft.PowerShell.SecretStore, qui demande par défaut un mot de passe tant que son authentification n'est pas reconfigurée.
3. macOS : enregistrer le secret une fois avec security add-generic-password -a "myservice" -s "myservice-token" -T /usr/bin/security -w ; avec -w en dernier et sans valeur, la commande demande la saisie, ce qui garde le secret hors de ps et de l'historique du shell. Un script le récupère avec security find-generic-password -a "myservice" -s "myservice-token" -w, qui n'affiche que la valeur. Le trousseau doit être déverrouillé, ce qui n'est souvent pas le cas du trousseau de session d'un utilisateur dans des sessions SSH ou pour des LaunchDaemons ; un outil absent de la liste d'accès de l'élément (-T) déclenche une invite graphique.
4. Dans les trois cas, restreindre le fichier ou le magasin de credentials au compte propre du service (Linux : s'appuyer sur le répertoire par service de LoadCredential= plutôt que sur un chemin partagé ; un fichier créé manuellement doit en outre être en chmod 0600).

Résultat attendu

Le secret est lisible à l'exécution par le compte de service prévu et par aucun autre ; une inspection de type ps//proc/<pid>/environ du processus en cours ne montre aucun secret en clair, et l'arrêt puis le redémarrage du processus ne demandent pas de le ressaisir manuellement.

Limites et base de vérification

Aucun de ces mécanismes n'empêche un processus tournant avec les mêmes privilèges que le service, ou un utilisateur pouvant exécuter sudo/Run as Administrator, de lire le secret en clair une fois déchiffré. Ce qu'ils permettent d'éviter : placer un secret dans une variable d'environnement (visible de tous les processus enfants et souvent journalisée), dans un argument de ligne de commande (visible dans ps/le Gestionnaire des tâches et dans l'historique du shell), ou dans un fichier ordinaire avec les permissions par défaut.