ConfigMaps, Secrets et bonnes pratiques

Séparer la configuration du code

Une bonne pratique fondamentale : ne jamais coder en dur une configuration (URL de base de données, clé API) dans l'image du conteneur. Kubernetes fournit deux objets dédiés.

ConfigMap : la configuration non sensible

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  API_URL: "https://api.exemple.com"
  LOG_LEVEL: "info"

Secret : les données sensibles

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_PASSWORD: bW90ZGVwYXNzZQ==

Les valeurs d'un Secret sont encodées en base64, pas chiffrées : ce n'est pas une protection cryptographique, seulement un évitement de caractères spéciaux. Un Secret doit être combiné avec le contrôle d'accès RBAC pour être réellement protégé.

Injecter dans un Pod

spec:
  containers:
    - name: web
      image: mon-app:latest
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secret

Bonnes pratiques de production

• Limites de ressources : toujours définir requests et limits (CPU/mémoire) pour éviter qu'un Pod ne monopolise un nœud entier.
• Sondes de santé (livenessProbe, readinessProbe) : permettent à Kubernetes de savoir si un Pod est réellement fonctionnel, pas seulement démarré.
• Ne jamais utiliser latest comme tag d'image en production : impossible de savoir quelle version tourne réellement, et les rollbacks deviennent aléatoires.

Cas concret

Une équipe change le mot de passe de sa base de données en modifiant directement le Secret Kubernetes. Sans redémarrage des Pods, l'ancienne valeur reste en mémoire dans les conteneurs déjà démarrés (les variables d'environnement ne se mettent pas à jour à chaud) : un kubectl rollout restart deployment est nécessaire pour propager le changement.

Erreurs fréquentes

• Croire qu'un Secret est chiffré parce qu'il est encodé en base64 : n'importe qui avec accès au cluster peut le décoder en une commande.
• Utiliser :latest en pensant avoir toujours la dernière version stable, alors que ça casse la traçabilité des déploiements.
• Oublier les limites de ressources : un Pod mal codé peut consommer toute la RAM d'un nœud et faire tomber les autres applications qui y tournent.

À retenir

• ConfigMap = configuration non sensible, Secret = données sensibles (encodées, pas chiffrées par défaut).
• Toujours définir des limites de ressources et des sondes de santé en production.
• Ne jamais utiliser le tag :latest pour un déploiement traçable.

Mini-exercice

Un Secret Kubernetes est modifié pour changer un mot de passe de base de données. Les Pods existants continuent d'utiliser l'ancien mot de passe. Pourquoi, et comment corriger ?

Réponse : les variables d'environnement d'un conteneur sont figées au démarrage du Pod, elles ne se mettent pas à jour à chaud. Il faut redémarrer les Pods (ex. kubectl rollout restart deployment) pour qu'ils relisent le Secret mis à jour.