Quand un secret doit être un fichier, pas une variable d'environnement
La plupart de ce dont une application a besoin est une simple paire KEY=VALUE, et la plupart des plateformes PaaS sont construites entièrement autour de cette hypothèse. Puis un JSON de compte de service Google Cloud apparaît — quelques kilo-octets de données d’identification structurées que les propres SDK de Google s’attendent à trouver à un chemin de fichier, pas à l’intérieur d’une variable d’environnement — et la solution de contournement habituelle est d’encoder tout ça en base64 dans une variable et de le décoder dans un script d’entrée. Ça fonctionne, mais c’est une solution de contournement, pas une fonctionnalité.
Le mécanisme réel
Variables → File secrets prend un nom et le contenu directement — jusqu’à 64 Ko, assez pour un JSON de compte de service, un certificat client, ou des identifiants structurés similaires. C’est stocké chiffré, comme n’importe quel autre secret, et monté en lecture seule à l’intérieur du conteneur à /etc/railyard/secrets/<name> — aucun aller-retour en base64, aucun script d’entrée qui décode une variable avant que l’application ne puisse démarrer.
La partie qui retire l’étape habituelle supplémentaire : son chemin est aussi exposé comme sa propre variable d’environnement, RAILYARD_SECRET_FILE_<NAME>. Une bibliothèque cliente Google qui attend que GOOGLE_APPLICATION_CREDENTIALS pointe vers un fichier reçoit simplement :
GOOGLE_APPLICATION_CREDENTIALS=${RAILYARD_SECRET_FILE_GCP_KEY_JSON}Aucune étape supplémentaire ne résout cette référence — c’est le même mécanisme de référence de variable que tout le reste, qui pointe vers un chemin plutôt qu’une valeur. Retirer un secret fichier prend effet au prochain déploiement, comme n’importe quel autre changement de variable.
Où ça se situe par rapport à tout le reste déjà automatique
Les services provisionnés injectent déjà leurs propres variables sans qu’on le demande — DATABASE_URL, les champs individuels DATABASE_HOST/PORT/USER/PASSWORD/NAME, REDIS_URL, les clés de stockage, RAILYARD_URL et consorts. Les propres variables documentées d’une application (les noms précis qu’elle indique avoir besoin, comme PGHOST ou BIND_ADDRESS) sont remplies depuis ces services automatiquement là où les noms correspondent, et les secrets que l’application possède elle-même — SECRET_KEY_BASE, APP_KEY, JWT_SECRET — sont générés une fois plutôt que laissés vides. Ce que ce mécanisme ne fait jamais, délibérément, c’est inventer un identifiant tiers à votre place — un compte de service GCP, une clé Stripe, tout ce qui appartient vraiment à un compte externe. Ceux-là sont toujours à vous de fournir, ce qui est exactement la catégorie pour laquelle les secrets fichiers existent.
Référencer un service plutôt que coder un hôte en dur
La même syntaxe de référence ${{...}} utilisée pour les chemins de secrets fichiers fonctionne entre services de façon générale : ${{api.RAILYARD_PRIVATE_URL}} se résout vers l’adresse privée de ce service à l’intérieur du même environnement, et ${config.KEY} tire depuis la configuration partagée de l’équipe disponible pour n’importe quelle application — le même motif, trois sources différentes, pour qu’une application n’ait jamais un hôte codé en dur ou un secret copié-collé qui dérive hors synchronisation avec l’endroit où vit vraiment la valeur.
Référence complète : Variables et secrets.