Configuration et secrets

Variables d'environnement, config maps, gestion sécurisée des secrets et outils comme Vault pour protéger les données sensibles.

Le principe : séparer la configuration du code

L’une des règles fondamentales du déploiement moderne est que la configuration ne doit pas résider dans le code. Le même artefact (image Docker, binaire, bundle) doit pouvoir s’exécuter dans n’importe quel environnement — la seule chose qui change, c’est la configuration.

Cela inclut :

Les URL des bases de données et des services externes
Les identifiants et jetons d’accès
Les feature flags et paramètres de comportement
Les niveaux de logging et les timeouts
Les clés d’API de tiers

Variables d’environnement

Les variables d’environnement constituent le mécanisme le plus basique et universel pour injecter la configuration dans une application.

Avantages

Prises en charge par tous les langages et plateformes
Faciles à configurer dans les conteneurs, la CI/CD et les fournisseurs cloud
Ne nécessitent aucune bibliothèque supplémentaire

Bonnes pratiques

# Nombres descriptivos en UPPER_SNAKE_CASE
DATABASE_URL=postgres://user:pass@host:5432/db
REDIS_URL=redis://localhost:6379
LOG_LEVEL=info
API_TIMEOUT_MS=5000
FEATURE_NEW_CHECKOUT=true

Utiliser un fichier .env.example dans le dépôt documentant toutes les variables nécessaires (sans valeurs réelles)
Ne jamais committer de fichiers .env contenant des valeurs réelles
Valider les variables au démarrage de l’application — échouer rapidement s’il manque une variable requise

Validation au démarrage

function validateEnv() {
  const required = ['DATABASE_URL', 'REDIS_URL', 'JWT_SECRET'];
  const missing = required.filter(key => !process.env[key]);
  if (missing.length > 0) {
    throw new Error(`Missing env vars: ${missing.join(', ')}`);
  }
}

ConfigMaps dans Kubernetes

Dans Kubernetes, les ConfigMaps permettent de stocker la configuration non sensible sous forme de paires clé-valeur et de les monter dans les pods.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_TIMEOUT: "30s"
  MAX_CONNECTIONS: "100"
  FEATURE_FLAGS: |
    {
      "newCheckout": true,
      "darkMode": false
    }

Injecter comme variables d’environnement

spec:
  containers:
    - name: my-app
      envFrom:
        - configMapRef:
            name: app-config

Monter comme fichier

spec:
  containers:
    - name: my-app
      volumeMounts:
        - name: config-volume
          mountPath: /app/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Gestion des secrets

Les secrets (mots de passe, jetons, clés privées) requièrent un traitement particulier. Ils ne doivent jamais se trouver dans :

Le code source
Les fichiers de configuration commités
Les logs de l’application
Les images Docker

Kubernetes Secrets

Kubernetes offre une ressource Secret pour les données sensibles :

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  DATABASE_PASSWORD: "mi-password-seguro"
  JWT_SECRET: "mi-jwt-secret"
  API_KEY: "mi-api-key"

Limitation importante : les Secrets de Kubernetes sont stockés dans etcd encodés en base64, mais ils ne sont pas chiffrés par défaut. Pour plus de sécurité, activez le chiffrement au repos (encryption at rest) ou utilisez un gestionnaire de secrets externe.

HashiCorp Vault

Vault est l’outil le plus populaire pour la gestion centralisée des secrets :

Stockage sécurisé : les secrets sont chiffrés au repos
Accès contrôlé : politiques granulaires définissant qui peut lire quels secrets
Rotation automatique : les secrets peuvent être renouvelés sans redéploiement
Audit : journalisation complète de qui a accédé à quel secret et quand
Secrets dynamiques : génère des identifiants temporaires à la demande (ex. : identifiants de BD qui expirent au bout d’une heure)

Autres outils

AWS Secrets Manager : gestion des secrets native dans AWS avec rotation automatique
Google Secret Manager : équivalent dans GCP
Azure Key Vault : équivalent dans Azure
SOPS : chiffre les fichiers de configuration qui peuvent ensuite être commités en toute sécurité

Rotation des secrets

Les secrets doivent être renouvelés périodiquement afin de minimiser l’impact d’une fuite :

Générer un nouveau secret : créer le nouvel identifiant dans le gestionnaire de secrets
Mettre à jour l’application : l’application lit le nouveau secret (idéalement sans redémarrage)
Vérifier le fonctionnement : confirmer que tout fonctionne avec le nouveau secret
Révoquer l’ancien secret : supprimer l’ancien identifiant

Rotation sans interruption

Pour effectuer une rotation des secrets sans interruption (downtime), l’application doit prendre en charge temporairement des dual credentials :

Accepter à la fois l’ancien et le nouveau secret pendant une période de transition
Une fois confirmé que tout fonctionne, révoquer l’ancien

Bonnes pratiques générales

Principe du moindre privilège : chaque service n’accède qu’aux secrets dont il a besoin
Ne pas logger les secrets : nettoyer les logs pour qu’ils n’affichent jamais d’identifiants
Chiffrer en transit et au repos : TLS pour la communication, chiffrement au repos pour le stockage
Auditer les accès : enregistrer qui accède à quels secrets et quand
Automatiser la rotation : ne pas dépendre de processus manuels pour renouveler les identifiants
Séparer configuration et secrets : la configuration non sensible va dans les ConfigMaps, les secrets dans un gestionnaire dédié

Résumé

La configuration et les secrets sont des aspects critiques du déploiement. Les variables d’environnement et les ConfigMaps gèrent la configuration non sensible, tandis que des outils comme Vault, AWS Secrets Manager ou Kubernetes Secrets protègent les données sensibles. La clé est de séparer la configuration du code, de valider au démarrage et de renouveler les secrets périodiquement.