Introduction

Le fichier .env est devenu un standard dans le développement logiciel pour stocker les variables d'environnement. Cependant, son utilisation a dépassé son objectif initial et est devenue un problème.

Problèmes avec .env

Le fichier .env ne permet pas de définir clairement les exigences de l'application, telles que les valeurs requises, les secrets, les valeurs par défaut, etc. Les équipes utilisent souvent d'autres fichiers, comme .env.example, pour stocker ces informations, ce qui peut entraîner des contradictions et des erreurs.

KEY=value

De plus, le fichier .env ne permet pas de gérer les secrets de manière sécurisée. Les valeurs sont stockées en clair et peuvent être accessibles à des personnes non autorisées.

Limites de l'utilisation de .env

L'utilisation de .env peut entraîner des problèmes de sécurité, tels que la fuite de secrets ou l'accès non autorisé à des informations sensibles. De plus, le fichier .env peut devenir difficile à gérer, notamment lorsqu'il s'agit de multiples environnements ou de déploiements.

Alternatives à .env

Il existe des alternatives à .env, telles que SecretSpec, qui permettent de définir les exigences de l'application de manière claire et sécurisée. SecretSpec utilise un fichier de déclaration qui est safe à committer et permet de gérer les secrets de manière sécurisée.

secretspec run

Cette approche permet de séparer les trois tâches suivantes : la déclaration des exigences, le stockage sécurisé des secrets et la livraison explicite des valeurs aux processus. Chaque pièce peut alors être modifiée de manière indépendante, ce qui facilite la gestion des secrets et des déploiements.