Beryl::Apply::SecretFile

Primitive secret-file : écrit un fichier dont une ou plusieurs parties sont injectées depuis des variables d'environnement (alimentées par le coffre chiffré de la société — cf. EnvFile#apply_all_to_env). Typiquement la PAIRE [utilisateur, mot de passe] d'un compte SMTP.

Les valeurs ne transitent JAMAIS par le YAML de recette, par git, par la ligne de commande, ni par les logs :

• la recette ne porte que des PLACEHOLDERS (@@USER@@, @@SECRET@@…) et les NOMS des variables d'env — jamais les valeurs ;

• les valeurs sont lues côté beryl dans ENV[...] au moment de l'apply, substituées en mémoire, puis écrites via write_file (transport SFTP — pas d'argv → pas de fuite ps) ;

• les messages (StepResult, dry-run) ne citent que le chemin, jamais le contenu.

  • secret-file: path: /usr/local/etc/dma/auth.conf mode: "0600" # défaut "0600" (fichier sensible) env: # placeholder → NOM de variable (coffre) "@@USER@@": SMTP_RELAY_USER "@@SECRET@@": SMTP_RELAY_PASSWORD content: | @@USER@@|{{ smarthost }}:@@SECRET@@

if_set: "{{ param }}" : paramètre vide → étape sautée, sans exiger la variable (secret d'une fonction qu'un serveur n'active pas encore).

Variables PAR SERVEUR : pour chaque nom, beryl cherche d'abord <HÔTE>__<NOM> (ex. WEB1__APP_AGENT_TOKEN ; ancienne forme <NOM>__<HÔTE> encore lue), puis <NOM>. Avec per_host: true, seule la variante du serveur est acceptée : un jeton ou une clé propre à chaque serveur n'est jamais pris dans la valeur commune.

Note : les noms de variables (sous-map env) sont en DUR — l'Executor n'interpole que les strings de premier niveau (donc content), pas les sous-maps. Les {{ … }} non secrets vont dans content.

Hérite de FileWrite pour l'idempotence (SHA-256) et l'écriture ; seules la résolution des valeurs et le mode par défaut diffèrent.