ISOSET: ConfigMaps et Secrets, La Gestion des Configurations Sensibles dans Kubernetes

Dans l’univers des applications conteneurisées orchestrées par Kubernetes, une question revient sans cesse : comment séparer efficacement le code de l’application de sa configuration ? Comment gérer les différences entre les environnements de développement, de recette et de production sans reconstruire l’image Docker à chaque fois ? Et surtout, comment traiter les informations sensibles comme les mots de passe, les clés API ou les certificats sans les exposer accidentellement ? Kubernetes répond à ces besoins fondamentaux avec deux objets natifs : les ConfigMaps pour les données non sensibles, et les Secrets pour les données confidentielles. Maîtriser ces ressources est une étape obligatoire pour tout développeur ou administrateur souhaitant déployer des applications robustes et sécurisées. Chez ISOSET, organisme de formation aux métiers du numérique, nous consacrons des modules entiers à ces mécanismes car ils sont au cœur des bonnes pratiques DevOps et de la sécurisation des clusters. Dans cet article de 2200 mots, nous allons explorer en détail ce que sont les ConfigMaps et les Secrets, comment les utiliser, les sécuriser, les intégrer dans des Helm Charts et les bonnes pratiques enseignées par nos formateurs experts.

1. ConfigMaps : externaliser la configuration non sensible

Une ConfigMap est une ressource Kubernetes qui permet de dissocier les données de configuration du conteneur lui-même. Au lieu d’enregistrer en dur les variables d’environnement, les URLs de services externes ou les paramètres de comportement dans le code ou dans l’image Docker, on les stocke dans une ConfigMap qui sera injectée dans le pod au moment de l’exécution. Cette approche suit le principe des Twelve-Factor App : la configuration doit être strictement séparée du code.

Créer une ConfigMap est simple avec kubectl create configmap ou via un fichier YAML. Par exemple :

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: postgresql://db-prod:5432/mydb
  LOG_LEVEL: info
  feature_flag_new_ui: "true"

On peut aussi la créer à partir d’un fichier (kubectl create configmap mon-config --from-file=app.properties) ou d’un répertoire entier. Une fois la ConfigMap présente, on l’injecte dans un pod de deux manières principales : via des variables d’environnement (avec valueFrom.configMapKeyRef) ou via un volume monté comme un fichier. La première méthode convient aux paramètres simples, la seconde aux fichiers de configuration complexes (par exemple nginx.conf ou application.yml).

Un cas d’usage typique : une application web qui doit parler à une base de données différente selon l’environnement. En développement, la ConfigMap pointera vers un service db-dev ; en production, vers db-prod. Sans changer une ligne de code ni reconstruire l’image, le déploiement s’adapte. C’est la promesse du configuration as code.

Cependant, les ConfigMaps ont leurs limites. La taille maximale d’une ConfigMap est de 1 MiB (par défaut, ajustable). Elles ne sont pas conçues pour stocker des données volumineuses (fichiers de plusieurs mégaoctets) ou des informations binaires. De plus, une modification de ConfigMap ne redémarre pas automatiquement les pods qui l’utilisent – un point que nous aborderons dans la section sur les défis avancés. Enfin, à partir de Kubernetes 1.22, il est possible de rendre une ConfigMap immuable (immutable: true), ce qui empêche toute modification et améliore la performance de l’API pour les ConfigMaps rarement changées.

Dans nos formations, ISOSET insiste sur l’importance de nommer proprement les ConfigMaps et de les versionner dans Git, à côté des manifests de déploiement. C’est le fondement de la GitOps : tout l’état souhaité du cluster, y compris la configuration, doit être stocké dans un dépôt.

2. Secrets : protéger les données sensibles

Les Secrets sont l’équivalent des ConfigMaps pour les informations confidentielles : mots de passe, tokens OAuth, clés SSH, certificats TLS, clés API, etc. Leur objectif est de soustraire ces données aux yeux non autorisés et d’éviter de les écrire en clair dans les manifests ou les images. Contrairement aux ConfigMaps, les Secrets sont encodés en base64 (et non chiffrés par défaut) et ne doivent jamais être transmis ou stockés en clair.

Un exemple de Secret YAML :

yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: dXNlcm5hbWU=      # base64 de "username"
  password: cGFzc3dvcmQ=      # base64 de "password"

On peut aussi utiliser stringData pour des valeurs en clair (converties automatiquement en base64). L’injection dans un pod se fait de manière analogue aux ConfigMaps, soit comme variables d’environnement, soit comme fichiers dans un volume. La méthode par volume est souvent préférable car elle réduit les risques d’exposition accidentelle (les commandes comme env dans un shell n’afficheront pas le secret). De plus, les secrets montés en volume sont mis à jour automatiquement sur le pod (bien que le pod ne redémarre pas, le fichier est actualisé).

Kubernetes propose plusieurs types de Secrets prédéfinis : kubernetes.io/service-account-token (créé automatiquement pour chaque ServiceAccount), kubernetes.io/dockercfg pour les registres d’images, kubernetes.io/tls pour les certificats. Le type Opaque est le plus générique.

La sécurité des Secrets repose sur plusieurs couches. Par défaut, les données sont stockées dans etcd (la base de données clé-valeur de Kubernetes) en base64 sans chiffrement. Cela signifie que toute personne ayant accès à etcd peut lire les secrets. Depuis Kubernetes 1.7, il est possible d’activer le chiffrement au repos (encryption at rest) via une EncryptionConfiguration. C’est une pratique indispensable pour les clusters sensibles. De plus, l’accès aux Secrets est régi par le RBAC : seuls les ServiceAccounts ou utilisateurs ayant explicitement le droit get ou list sur les Secrets peuvent les consulter.

Malgré ces protections, les Secrets Kubernetes ne sont pas une solution magique. Ils ne sont pas chiffrés de bout en bout, ils sont visibles en base64 par toute personne ayant kubectl get secret -o yaml sur le cluster, et ils transitent en clair sur le réseau si le traffic interne n’est pas chiffré (mTLS peut aider). C’est pourquoi ISOSET recommande d’aller plus loin avec des outils comme Sealed Secrets, SOPS, ou External Secrets Operator (voir section suivante). Mais avant d’arriver là, il est essentiel de maîtriser les Secrets natifs.

3. Bonnes pratiques de sécurité pour les Secrets

Une erreur fréquente chez les débutants consiste à versionner des fichiers YAML contenant des secrets encodés en base64 dans un dépôt Git public. Or le base64 n’est pas un chiffrement : n’importe qui peut le décoder. La première règle est donc : ne jamais committer un Secret non chiffré dans Git. Pour contourner cette limitation, plusieurs solutions se sont imposées.

Sealed Secrets (Bitnami) est l’une des plus populaires. Elle repose sur un contrôleur Kubernetes et un outil client kubeseal. Le principe : on chiffre un Secret avec une clé publique du cluster ; le résultat (le SealedSecret) peut être stocké en toute sécurité dans Git. Seul le contrôleur dans le cluster peut déchiffrer et créer le Secret natif. Cela permet d’avoir des manifests « scellés » versionnés.

SOPS (Secrets OPerationS) intégré avec Mozilla sops et un backend comme AWS KMS, GCP KMS ou age. Il chiffre des fichiers YAML ou JSON complets, pas seulement des Secrets Kubernetes. Très flexible, il est souvent utilisé avec Helm.

External Secrets Operator (ESO) va encore plus loin : il ne stocke aucun secret dans Kubernetes ; il va chercher les valeurs à la volée dans un gestionnaire externe (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Le secret Kubernetes natif est créé localement par l’opérateur et synchronisé périodiquement. C’est la solution préférée des entreprises ayant une gouvernance centralisée des secrets.

En complément, il est recommandé d’activer le chiffrement au repos d’etcd, de limiter les accès RBAC aux Secrets avec des rôles très fins (éviter les *), d’utiliser des ServiceAccounts dédiés pour chaque application, et de mettre en place une politique de rotation des secrets. Kubernetes ne gère pas la rotation automatique ; c’est à l’application ou à un opérateur (comme Reloader ou Stakater avec des annotations) de détecter les changements et de redémarrer les pods.

ISOSET (nos formations s’adressent aussi aux jeunes talents) propose des ateliers pratiques sur la mise en place de Sealed Secrets et d’External Secrets Operator dans un cluster de test. Les apprenants repartent avec une boîte à outils concrète pour sécuriser leurs déploiements.

4. Intégration avec Helm : templating des ConfigMaps et Secrets

Lorsqu’on utilise Helm Charts (voir notre précédent article), la gestion des ConfigMaps et Secrets devient encore plus puissante. Grâce au templating Go, on peut générer dynamiquement ces ressources à partir d’un fichier values.yaml. Par exemple, un template de ConfigMap peut être écrit ainsi :

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-config
data:
  {{- range $key, $val := .Values.appConfig }}
  {{ $key }}: {{ $val | quote }}
  {{- end }}

Dans values.yaml : appConfig: { DATABASE_URL: "postgresql://...", LOG_LEVEL: "debug" }

Pour les Secrets, le même mécanisme s’applique, mais attention à ne pas mettre de valeurs en clair dans values.yaml versionné. La solution classique consiste à utiliser un plugin comme helm-secrets (qui s’appuie sur SOPS) ou à intégrer Sealed Secrets directement dans le Chart. Une autre approche est d’utiliser lookup (une fonction Helm qui lit les ressources existantes dans le cluster) pour rendre le déploiement idempotent – notamment pour les secrets générés aléatoirement (mot de passe de base de données) que l’on ne veut pas recréer à chaque helm upgrade.

Un pattern avancé : utiliser {{ .Files.Get "configs/app.conf" | toYaml | indent 2 }} pour embarquer un fichier de configuration complet dans un ConfigMap. Cela évite de dupliquer le contenu dans le template.

L’intégration de Secrets avec Helm soulève toutefois des questions de sécurité : où stocker les valeurs des secrets en amont ? La meilleure pratique aujourd’hui est d’utiliser Helm + External Secrets Operator : le Chart ne contient que la définition d’un ExternalSecret (ou d’un SealedSecret), et les vraies valeurs résident dans Vault ou le gestionnaire de secrets du cloud. Ainsi, le Chart reste propre et peut être partagé sans risque.

Chez ISOSET, nous avons développé une méthodologie en quatre niveaux de maturité pour la gestion des configurations sous Helm :

Niveau 1 : ConfigMaps et Secrets codés en dur dans values.yaml (non recommandé).
Niveau 2 : Séparation des environnements via values-dev.yaml, values-prod.yaml stockés en local (moyen).
Niveau 3 : Utilisation de helm-secrets avec SOPS pour chiffrer les valeurs sensibles dans Git.
Niveau 4 : External Secrets Operator ou Sealed Secrets, avec stockage des secrets dans un coffre-fort externe.

Chaque niveau est enseigné dans nos cursus selon le public (débutant, confirmé, expert).

5. Défis et solutions avancées : mise à jour, redémarrage et observabilité

Un écueil classique avec ConfigMaps et Secrets est que leur modification ne provoque pas le redémarrage des pods qui les utilisent. Si vous changez une variable d’environnement via une ConfigMap, les pods déjà lancés continuent à voir l’ancienne valeur. Il faut donc soit supprimer et recréer les pods manuellement, soit utiliser un outil qui détecte les changements et déclenche un rolling update.

La solution la plus répandue est d’ajouter une annotation sur le Deployment contenant un checksum (MD5 ou SHA) du contenu de la ConfigMap/Secret. Dans un Helm Chart, on écrit typiquement :

yaml

annotations:
  checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

À chaque changement de la ConfigMap, le checksum change, ce qui force Kubernetes à recréer les pods (rolling update). C’est une méthode propre et déclarative. Pour les Secrets, le même principe s’applique.

Si vous préférez une approche sans Helm, des contrôleurs comme Reloader (de Stakater) ou kube-reloader surveillent les ConfigMaps et Secrets et déclenchent un rolling restart des Deployments, DaemonSets ou StatefulSets associés via des annotations du type reloader.stakater.com/match: "true".

Un autre défi concerne la taille : rappelons la limite de 1 MiB pour une ConfigMap ou un Secret. Pour des fichiers de configuration plus volumineux, il faut envisager des solutions alternatives comme des volumes NFS, des ConfigMaps multiples, ou l’utilisation d’un service externe (Consul, etcd dédié). Pour les Secrets, dépasser 1 MiB est rare, mais dans le cas de certificats volumineux (CRL, chaînes longues), il faut scinder.

Enfin, l’observabilité des ConfigMaps et Secrets est souvent négligée. Quelles sont les ConfigMaps actuellement montées sur un pod donné ? Quel pod utilise tel Secret ? Des outils comme kubectl describe pod ou des solutions de visualisation (K9s, Lens, Octant) aident. Dans un contexte de sécurité, il est recommandé d’auditer régulièrement les accès aux Secrets via les logs de l’API server (avec des outils comme Falco ou Audit2rbac).

ISOSET – nos formateurs sont des experts Kubernetes – intègre ces cas pratiques dans les travaux dirigés : les stagiaires doivent déployer une application avec une ConfigMap modifiable, puis automatiser le redémarrage via checksum, et enfin mettre en place Reloader. Ces compétences sont systématiquement testées en fin de module.

6. Se former à la gestion des configurations avec ISOSET

lle est également indispensable pour passer à l’échelle dans un environnement de production. Chez ISOSET, nous avons conçu des parcours de formation qui couvrent non seulement la théorie, mais surtout la pratique en situation réelle.

Nos formations Kubernetes (initiation, perfectionnement, sécurité) consacrent des ateliers spécifiques à :

Création et injection de ConfigMaps/Secrets via CLI et YAML.
Bonnes pratiques de nommage, immutabilité, gestion des environnements.
Mise en place du chiffrement au repos d’etcd.
Utilisation de Sealed Secrets et External Secrets Operator sur un cluster multi-nœuds.
Intégration avec Helm Charts (templating, checksum, helm-secrets).
Automatisation du redémarrage des pods avec annotations et Reloader.
Audit et rotation des secrets.

Les apprenants travaillent sur des cas concrets : déployer une application WordPress avec des secrets pour la base de données MySQL (via Sealed Secrets), ou encore une API Node.js dont la configuration change dynamiquement selon l’environnement (dev/staging/prod) en utilisant un seul Chart Helm. Tous les exercices sont réalisés sur des clusters cloud (AWS EKS, Azure AKS, ou GCP GKE) pour coller au plus près des conditions réelles.

L’originalité d’ISOSET est de former aussi bien des développeurs back-end que des administrateurs systèmes ou des responsables sécurité. Nous adaptons le discours : pour les devs, nous insistons sur l’ergonomie et l’intégration dans les pipelines CI/CD ; pour les ops, sur la sécurisation et la surveillance ; pour les security, sur le chiffrement et la gestion des accès. Chaque participant repart avec une cheatsheet personnalisée et des exemples de code prêts à être réutilisés.

Les témoignages de nos anciens stagiaires, disponibles sur notre site, montrent que cette compétence est immédiatement valorisée par les employeurs.

ConfigMaps et Secrets : des briques essentielles pour des applications Kubernetes robustes

ConfigMaps et Secrets ne sont pas des fonctionnalités exotiques de Kubernetes ; ce sont des mécanismes fondamentaux que tout professionnel du conteneur doit maîtriser. Ils permettent de respecter le principe de séparation code / configuration, de faciliter la mobilité des applications entre environnements, et de protéger les informations sensibles contre les fuites accidentelles. Associés à Helm, ils offrent une expérience de déploiement déclarative, versionnée et reproductible. Et avec des outils complémentaires comme Sealed Secrets, External Secrets Operator ou Reloader, on peut même dépasser les limitations natives de Kubernetes.

La gestion de la configuration est souvent sous-estimée, pourtant c’est elle qui détermine la fiabilité et la sécurité de votre infrastructure en production. Une mauvaise pratique (secret en clair dans un repo, ConfigMap surchargée, pod non redémarré après changement) peut entraîner des incidents graves, voire des brèches de sécurité. Se former auprès d’un organisme reconnu comme ISOSET est la garantie d’acquérir les bons réflexes, de comprendre les trade-offs et de savoir naviguer dans l’écosystème riche des outils cloud natifs.

Nous vous invitons à consulter notre catalogue de formations Kubernetes sur notre site. Que vous soyez débutant ou expert, que vous cherchiez une formation inter-entreprise, intra-entreprise ou un cursus pour grand public, ISOSET a une solution adaptée. Nos prochaines sessions abordent spécifiquement la sécurité des Secrets et l’intégration avec GitOps. Rejoignez-nous pour passer de la théorie à la pratique, et faites de vos déploiements un modèle de robustesse.

Linkedin : https://fr.linkedin.com/company/isoset
Facebook : https://www.facebook.com/isosetfrance/
Instagram : https://www.instagram.com/isosetsa/