IT Toolbox AI
Kubernetes · ConfigMaps et Secrets

ConfigMaps et Secrets

Externalisez la configuration et protégez les données sensibles sans les intégrer aux images.

Leçon disponible
20 min

Objectifs

  • Distinguer configuration non sensible et données confidentielles.
  • Créer des manifests ConfigMap et Secret valides.
  • Injecter des valeurs via variables d’environnement ou volumes.
  • Comprendre les limites du Base64 et éviter l’exposition des secrets.

Configurer les applications avec ConfigMaps et Secrets

Externaliser la configuration permet de réutiliser une même image dans plusieurs environnements. Une ConfigMap contient des données non confidentielles ; un Secret est destiné aux données sensibles et bénéficie de contrôles d’accès spécifiques.

Un Secret Kubernetes n’est pas automatiquement sûr par sa seule existence. Les valeurs du champ data sont encodées en Base64, ce qui n’est pas du chiffrement ; la sécurité dépend aussi du RBAC, du chiffrement au repos et du système de gestion des secrets.

ConfigMap pour la configuration non sensible

Le champ data accepte des paires clé-valeur texte. La ConfigMap peut ensuite être consommée comme environnement ou montée sous forme de fichiers.

configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info

Secret et stringData

stringData accepte des chaînes lisibles à la création ; l’API les convertit dans data. La valeur change-me est uniquement pédagogique et ne doit jamais être réutilisée dans un environnement réel.

secret.yaml pédagogique — ne pas committer avec de vraies valeurs
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
stringData:
  DB_USER: appuser
  DB_PASSWORD: change-me

N’enregistrez jamais un vrai mot de passe en clair dans Git. Selon l’architecture, utilisez un gestionnaire de secrets, Vault, External Secrets ou un mécanisme équivalent avec rotation et contrôle d’accès.

Utiliser les valeurs dans un Pod

envFrom crée des variables à partir de toutes les clés référencées. Des références plus ciblées ou des volumes projetés conviennent lorsque seules certaines clés sont nécessaires.

Extrait du container dans un Pod template
envFrom:
  - configMapRef:
      name: app-config
  - secretRef:
      name: app-secret

Une variable d’environnement déjà injectée ne change pas dans un processus existant après la mise à jour de la ConfigMap ou du Secret. Le workload doit généralement être redémarré ou rechargé selon son mode de consommation.

Observer sans exposer les valeurs sensibles

Listez les objets et décrivez la ConfigMap. Pour les Secrets, évitez les sorties qui décodent ou affichent les valeurs dans un terminal, un historique de commandes ou des logs de CI.

Inventaire prudent
kubectl get configmaps
kubectl get secrets
kubectl describe configmap app-config

Bonnes pratiques

Accordez l’accès minimal aux Secrets, activez le chiffrement au repos lorsque nécessaire et prévoyez la rotation. Séparez les configurations par application et environnement.

  • Ne pas placer de secret réel dans une image, un manifeste versionné ou une ConfigMap.
  • Restreindre les droits get/list/watch sur les Secrets avec RBAC.
  • Prévoir comment l’application recharge une configuration mise à jour.

Mini résumé

  • ConfigMap stocke une configuration non confidentielle.
  • Secret est l’objet adapté aux données sensibles, mais Base64 ne chiffre rien.
  • envFrom et les volumes permettent de consommer les valeurs dans un Pod.
  • RBAC, chiffrement au repos et rotation complètent la protection.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Où placer un niveau de log non sensible ?
2. Que garantit le Base64 utilisé dans data d’un Secret ?
3. Une ConfigMap injectée via envFrom change. Le processus existant reçoit-il automatiquement la nouvelle variable ?