Pourquoi utiliser ConfigMaps et Secrets dans Kubernetes ?

Les applications modernes, particulièrement dans les environnements cloud-native, sont souvent réparties sur plusieurs services et environnements. Elles ont besoin d’une configuration dynamique, adaptable et surtout sécurisée. Ces configurations incluent aussi bien des paramètres non sensibles comme des ports, des URLs ou des noms d’environnement, que des secrets tels que des mots de passe, des tokens d’authentification ou des clés API.

Dans Kubernetes, il est fortement déconseillé de coder ces informations dans les conteneurs. À la place, la plateforme fournit deux objets essentiels pour la gestion de la configuration : ConfigMap pour les données non sensibles, et Secret pour les informations confidentielles. Leur utilisation permet d’adopter une approche 12-Factor App, où la configuration est externalisée du code.

L’utilisation judicieuse de ces objets permet une meilleure portabilité des applications, une plus grande flexibilité dans les déploiements et une sécurité accrue des environnements de production. Ils sont également compatibles avec les processus CI/CD, permettant une automatisation complète et traçable des mises à jour.

---

Qu’est-ce qu’un ConfigMap ?

Un ConfigMap est une ressource Kubernetes conçue pour stocker des paramètres de configuration non sensibles sous forme de paires clé-valeur. Il est particulièrement utile pour définir des variables d’environnement, des fichiers de configuration, ou même des scripts entiers que les Pods peuvent consommer.

Cas d’usage typiques :

• Définir l’environnement (dev, staging, prod)
• Ajouter des paramètres spécifiques à une région ou à un cluster
• Centraliser les chemins de fichiers ou URLs d’API
• Injecter des fichiers de configuration entiers dans un volume

Avantages :

• Flexibilité accrue : pas besoin de reconstruire l’image du conteneur pour changer une configuration.
• Interopérabilité : utilisable par tous les types de workloads Kubernetes (Deployments, CronJobs, StatefulSets, etc.)
• Maintenance facilitée : centralisation des paramètres communs à plusieurs Pods

Création d’un ConfigMap :

En ligne de commande (valeurs simples) :

kubectl create configmap mon-configmap --from-literal=ENV=dev --from-literal=TIMEOUT=30

À partir d’un fichier de configuration :

kubectl create configmap mon-configmap --from-file=app.properties

En YAML (recommandé pour CI/CD) :

apiVersion: v1
kind: ConfigMap
metadata:
  name: mon-configmap
data:
  ENV: dev
  TIMEOUT: "30"

Utilisation dans un Pod :

1. Variables d’environnement :

env:
  - name: ENV
    valueFrom:
      configMapKeyRef:
        name: mon-configmap
        key: ENV

2. Volumes montés :

volumes:
  - name: config-vol
    configMap:
      name: mon-configmap
volumeMounts:
  - name: config-vol
    mountPath: /etc/config

3. Arguments de ligne de commande :

command: ["/bin/myapp"]
args: ["--env", "/etc/config/ENV"]

Mise à jour d’un ConfigMap :

• Modification via kubectl edit configmap ...
• Réapplication d’un YAML modifié
• Redémarrage du Pod ou rechargement automatique via un sidecar (ex: Reloader)

---

Qu’est-ce qu’un Secret ?

Un Secret est une ressource Kubernetes utilisée pour stocker de manière sécurisée des données sensibles, comme des mots de passe, des certificats, des clés privées ou des jetons d’accès. À la différence des ConfigMaps, les Secrets sont encodés en base64 et peuvent être chiffrés nativement au repos dans le cluster.

Kubernetes supporte différents types de Secrets :

• Opaque (par défaut)
• kubernetes.io/tls pour des certificats
• kubernetes.io/dockerconfigjson pour l’authentification à un registre

Exemples d’usage :

• Identifiants de base de données MySQL/PostgreSQL
• Clé API pour Stripe ou SendGrid
• Fichier .dockerconfig.json pour des images privées
• Paires de clés SSH pour Git

Création d’un Secret :

Depuis le terminal :

kubectl create secret generic mes-identifiants --from-literal=username=admin --from-literal=password=s3cr3t

Avec un fichier YAML (avec données encodées en base64) :

apiVersion: v1
kind: Secret
metadata:
  name: mes-identifiants
type: Opaque
data:
  username: YWRtaW4=
  password: czNjcjN0

Depuis un fichier :

kubectl create secret generic credentials --from-file=secret.txt

Utilisation dans un Pod :

1. En tant que variable d’environnement :

env:
  - name: DB_USER
    valueFrom:
      secretKeyRef:
        name: mes-identifiants
        key: username

2. En tant que volume :

volumes:
  - name: secret-vol
    secret:
      secretName: mes-identifiants
volumeMounts:
  - name: secret-vol
    mountPath: /etc/creds

Les fichiers montés depuis un Secret sont en lecture seule avec des permissions sécurisées (0400).

Mise à jour d’un Secret :

• Modifier avec kubectl edit secret ...
• Réappliquer un fichier YAML mis à jour
• Déclencher un redéploiement ou utiliser un mécanisme comme External Secrets Operator

---

Comparaison : ConfigMap vs Secret

Caractéristique	ConfigMap	Secret
Type de données	Paramètres non sensibles	Informations confidentielles
Encodage	Aucun	Encodage base64
Chiffrement au repos	Non	Oui (optionnel mais recommandé)
Accès via RBAC	Contrôle standard	Contrôle renforcé
Taille maximale	1 Mo	1 Mo
Exemples	URL, flags, noms d’environnement	Mots de passe, tokens, clés SSH

---

Bonnes pratiques DevOps

1. Séparer strictement config et secrets : Ne jamais stocker de données sensibles dans un ConfigMap.
2. Chiffrer les Secrets au repos avec une clé KMS dans la configuration EncryptionConfiguration.
3. Restreindre l’accès via RBAC aux utilisateurs, groupes ou service accounts.
4. Ne jamais exposer un Secret via une UI ou un kubectl describe. Utiliser kubectl get secret ... -o jsonpath avec précaution.
5. Audit et journalisation : activer les logs d’accès à l’API Kubernetes pour suivre les lectures de Secrets.
6. Rotation régulière des secrets : planifier des renouvellements périodiques et automatisés.
7. GitOps sécurisé : utiliser Sealed Secrets, SOPS, ou un gestionnaire comme Vault.
8. Outils utiles : reloader, external-secrets, hashicorp/vault-k8s, etc.
9. Intégration CI/CD : injecter dynamiquement des ConfigMaps/Secrets dans vos pipelines pour les environnements dev/test/prod.

---

Conclusion

Les ConfigMaps et Secrets sont des éléments incontournables de toute architecture Kubernetes bien pensée. Ils permettent non seulement d’améliorer la portabilité et la maintenabilité des applications, mais aussi de garantir une sécurité robuste, adaptée aux enjeux actuels des systèmes distribués.

Grâce à une bonne implémentation de ces objets, vous facilitez la gestion de vos configurations, vous sécurisez vos accès aux ressources critiques, et vous posez les bases d’un écosystème DevOps efficace et auditable. Leur maîtrise est donc indispensable pour tout administrateur ou développeur travaillant sur Kubernetes.

---

FAQ

Q : Les Secrets sont-ils automatiquement chiffrés dans Kubernetes ?
R : Non, uniquement encodés en base64. Il faut activer le chiffrement au repos dans la configuration de l’API server.

Q : Peut-on mettre à jour une configuration sans redémarrer un Pod ?
R : Oui, si l’application lit dynamiquement les fichiers. Sinon, un redémarrage est requis.

Q : Quelle est la limite de taille pour un Secret ou un ConfigMap ?
R : 1 Mo par objet Kubernetes.

Q : Peut-on intégrer un Secret contenant un certificat SSL ?
R : Oui, en utilisant le type kubernetes.io/tls ou en encodant manuellement les fichiers.

Q : Peut-on versionner des Secrets ?
R : Pas nativement. Utilisez GitOps avec Sealed Secrets ou un gestionnaire externe.

Q : Peut-on partager un ConfigMap entre plusieurs Pods ?
R : Oui, s’ils sont dans le même namespace.

Q : Existe-t-il une alternative aux Secrets natifs ?
R : Oui, des outils comme Vault, AWS Secrets Manager ou Azure Key Vault offrent des fonctionnalités avancées.

---