Comment fonctionnent les ConfigMaps et les Secrets pour injecter de la configuration dans les workloads ?

Question

IT Interview Practice · Accepted Answer

Les **ConfigMaps** et les **Secrets** découplent la configuration des images de conteneurs, de sorte que la même image tourne en dev, staging et production avec des réglages différents. Les ConfigMaps contiennent la config **non sensible** ; les Secrets contiennent les données **sensibles** (mots de passe, tokens, clés) et sont manipulés avec plus de précaution.

## L'idée : sortir la config de l'image

```text
Image = code (immuable, construit une fois).  Config = valeurs par environnement.
Intégrer la config dans l'image est un anti-pattern (reconstruire par env, fuite de secrets).
→ Stockez la config dans des ConfigMaps/Secrets, injectez-la à l'exécution en variables d'env ou fichiers.
```

## ConfigMap : réglages non sensibles

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret : valeurs sensibles

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # texte en clair ici ; stocké encodé en base64 dans etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Généralement créé de façon impérative pour éviter de committer les secrets dans git :
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injection dans un Pod : en variables d'env ou en fichiers

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # une seule clé depuis une ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # une seule clé depuis un Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importer TOUTES les clés comme variables d'env
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # monter la config sous forme de fichiers
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Mises en garde importantes sur les Secrets

```text
⚠ Les données d'un Secret sont ENCODÉES en base64, pas chiffrées, par défaut.
  → Activez le CHIFFREMENT AU REPOS pour etcd (EncryptionConfiguration).
  → Restreignez l'accès avec RBAC (qui peut faire 'get secrets').
  → Préférez des gestionnaires externes (Vault, cloud Secrets Manager) ou des sealed secrets.
  → Ne committez jamais de vrais manifests de Secret dans git.
La config en variable d'env est lue UNE FOIS au démarrage du conteneur ; les fichiers montés peuvent se mettre à jour à chaud.
```

## Pourquoi c'est important

Séparer la configuration du code est une pratique opérationnelle fondamentale, et les ConfigMaps et Secrets sont la façon dont Kubernetes l'implémente, donc les comprendre est une connaissance essentielle de niveau intermédiaire. Intégrer des réglages spécifiques à l'environnement dans une image est un anti-pattern — cela force une reconstruction par environnement et risque de faire fuiter des secrets — donc Kubernetes vous permet de garder une seule image immuable et d'injecter la configuration à l'exécution : les **ConfigMaps** pour les valeurs non sensibles (niveaux de log, feature flags, fichiers de config) et les **Secrets** pour les données sensibles (mots de passe, tokens, clés). Connaître les deux façons de les consommer — en **variables d'environnement** (clés individuelles via `configMapKeyRef`/`secretKeyRef`, ou toutes les clés via `envFrom`) et en **fichiers montés** (avec la nuance que les variables d'env sont lues une fois au démarrage tandis que les fichiers montés peuvent se mettre à jour à chaud) — est une connaissance pratique de tous les jours pour déployer de vraies applications. Tout aussi important est de comprendre les mises en garde de sécurité qui piègent beaucoup d'ingénieurs : les données d'un Secret sont seulement **encodées en base64, pas chiffrées**, par défaut, donc les protéger réellement nécessite d'activer le **chiffrement au repos** pour etcd, de restreindre l'accès avec **RBAC**, d'éviter de committer les manifests de Secret dans le contrôle de version, et souvent d'intégrer un gestionnaire de secrets externe. Parce que pratiquement chaque workload a besoin d'une configuration et de credentials par environnement, et parce que mal gérer les Secrets est une faille de sécurité fréquente et grave, une bonne maîtrise des ConfigMaps et des Secrets est fondamentale pour faire tourner des applications de façon sûre et correcte sur Kubernetes.

L'idée : sortir la config de l'image

ConfigMap : réglages non sensibles

Secret : valeurs sensibles

Injection dans un Pod : en variables d'env ou en fichiers

Mises en garde importantes sur les Secrets

Pourquoi c'est important

Questions connexes