Kubernetes 026 – ConfigMap et Secrets : variables, fichiers et montage

TL;DR

Une ConfigMap stocke de la configuration non sensible. Un Secret stocke des donnees sensibles, avec encodage base64 mais pas chiffrement applicatif automatique. Les deux peuvent etre injectes en variables d’environnement ou montes comme fichiers.

La video de reference

Video: https://www.youtube.com/watch?v=cMzEl3I9qsc

Elle introduit la configuration externe avant de revenir au TP Dockercoin.

ConfigMap simple

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: info
  APP_MODE: demo

Injection en variables:

envFrom:
  - configMapRef:
      name: app-config

Secret simple

kubectl create secret generic db-secret --from-literal=password='change-me'
kubectl get secret db-secret -o yaml

Dans le YAML, la valeur est encodee en base64. Cela ne signifie pas qu’elle est protegee contre toute lecture.

Monter comme fichiers

volumes:
  - name: config
    configMap:
      name: app-config
containers:
  - name: app
    image: nginx
    volumeMounts:
      - name: config
        mountPath: /etc/app

Chaque cle devient un fichier dans le repertoire monte.

Variables precises

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: LOG_LEVEL

Cette forme est plus explicite que envFrom.

Liens utiles

• Video: https://www.youtube.com/watch?v=cMzEl3I9qsc
• ConfigMaps: https://kubernetes.io/docs/concepts/configuration/configmap/
• Secrets: https://kubernetes.io/docs/concepts/configuration/secret/
• Configure a Pod: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

FAQ

Un Secret est-il chiffre ?

Pas par defaut au sens applicatif. Il est encode et peut etre chiffre au repos selon la configuration du cluster.

Changer une ConfigMap redemarre-t-il les pods ?

Pas automatiquement pour les variables d’environnement. Les volumes peuvent etre mis a jour, mais l’application doit relire.

Faut-il mettre la configuration dans l’image ?

Non, pas si elle varie selon l’environnement.

Erreurs frequentes

• Committer des Secrets en clair dans Git.
• Croire que base64 est une securite.
• Modifier une ConfigMap sans redemarrer une application qui lit au demarrage.
• Melanger configuration publique et mots de passe.

Pour pratiquer

kubectl create configmap app-config --from-literal=LOG_LEVEL=debug
kubectl create secret generic app-secret --from-literal=TOKEN=demo
kubectl describe configmap app-config
kubectl describe secret app-secret

Notions et definitions

• ConfigMap: configuration non sensible injectee dans les pods.
• Secret: donnees sensibles encodees et gerees comme ressource Kubernetes.
• Label et annotation: metadata servant respectivement a selectionner et a documenter/enrichir les objets.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Une application peut lire son niveau de log depuis une ConfigMap et son mot de passe depuis un Secret, sans reconstruire l’image Docker.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Sortir les valeurs variables de l’image applicative.
• Creer une ConfigMap ou un Secret selon la sensibilite de la donnee.
• Injecter la valeur en variable d’environnement ou en fichier monte.
• Verifier dans le pod que la valeur est disponible au bon endroit.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser la separation entre image applicative, configuration, metadata et parametrage d’execution. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get configmap,secret --show-labels
• kubectl describe pod <pod> pour verifier variables, volumes et references
• kubectl get all -l <cle>=<valeur> pour valider l’usage des labels

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• stocker une configuration variable directement dans l’image
• confondre Secret Kubernetes et coffre-fort de secrets complet
• sous-estimer l’importance des labels pour filtrer, selectionner et automatiser

Exercice conseille

Externalisez une variable d’environnement dans une ConfigMap, montez-la dans un pod, changez sa valeur, puis observez ce qui change sans redeployer et ce qui demande un redemarrage.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 027 – TP Dockercoin : ConfigMaps et Services.

Conclusion

ConfigMap et Secret rendent les manifests plus propres et les images plus reutilisables. Ils sont indispensables avant de deployer des applications configurables proprement.