Pourquoi les secrets n'ont pas leur place dans les variables d'environnement

Un billet d'opinion remet en question la pratique courante consistant à transmettre les secrets via des variables d'environnement, plaidant pour un chargement direct depuis une configuration structurée au sein du code applicatif.

Premier argument de l'auteur : la cohérence. Mélanger des fichiers de configuration ini/yaml/json avec des variables d'environnement séparées (comme c'est souvent le cas dans les configurations Docker, réparties entre fichiers compose et fichiers .env) produit une configuration fragmentée et source d'erreurs.

Deuxièmement, charger les secrets depuis l'application elle-même évite les bizarreries d'injection propres à certaines plateformes. L'auteur se souvient d'un ancien emploi où les secrets étaient récupérés à l'exécution depuis S3, l'application tournant sur AWS ECS — car y définir des variables d'environnement risquait de les faire fuiter via la console ECS.

Troisièmement, l'auteur ne s'inquiète guère de stocker des secrets sur disque, car il utilise systématiquement le chiffrement complet du disque, complété par encfs/gocryptfs si nécessaire. Si un attaquant parvenait à contourner les deux, c'est toute la machine qui serait de toute façon compromise — les variables d'environnement n'offriraient pas plus de sécurité.

Enfin, pour des applications aux structures de données complexes et profondément imbriquées, l'auteur trouve JSON/YAML bien plus maniable que des variables d'environnement à plat.