Environment Variable Security

Définition

La sécurité des variables d'environnement (Environment Variable Security) couvre les pratiques permettant de protéger les informations sensibles transmises via les variables d'environnement aux applications et processus. Les variables d'environnement sont largement utilisées dans les architectures 12-factor apps pour séparer la configuration du code, mais leur gestion sécurisée requiert des précautions spécifiques pour éviter leur exposition accidentelle. Les variables d'environnement présentent plusieurs risques de sécurité. Elles peuvent être listées par des processus filleuls (env, /proc/{pid}/environ sous Linux), ce qui signifie qu'une commande exécutée dans le contexte de l'application peut exfiltrater toutes les variables d'environnement incluant les secrets. Elles peuvent apparaître dans les dumps de crash, les logs de debug, et les métadonnées de déploiement (kubectl describe pod, docker inspect) si elles ne sont pas filtrées. Des vulnérabilités applicatives comme les Server-Side Template Injections ou les RCE peuvent lire les variables d'environnement et les exfiltrer. Dans les conteneurs Docker et Kubernetes, les variables d'environnement présentent des risques spécifiques. Les Kubernetes Secrets stockant des données en Base64 (pas chiffrés par défaut dans etcd) peuvent être lus par quiconque a accès à l'API Kubernetes. Les variables d'environnement injectées via envFrom/env dans les specs de pods apparaissent en clair dans la spécification du pod (kubectl get pod -o yaml), visible à quiconque peut lire les pods dans le namespace. Les meilleures pratiques incluent : l'utilisation de secrets managers (Vault, AWS Secrets Manager, External Secrets Operator) plutôt que des variables d'environnement pour les secrets les plus sensibles, le chiffrement d'etcd pour les Kubernetes Secrets, les annotations sealed-secrets ou External Secrets pour les workflows GitOps, la configuration explicite des secrets comme "masked" dans les variables CI/CD (GitLab CI, GitHub Actions), et la limitation des permissions d'accès aux variables d'environnement dans les pods Kubernetes. L'injection de secrets au démarrage de l'application (via un init container récupérant les secrets depuis Vault) plutôt que comme variables d'environnement statiques est une pratique plus sécurisée : les secrets sont présents uniquement en mémoire de l'application, pas dans la configuration visible du pod.