Kubernetes ConfigMaps
| Fiche express | |
|---|---|
| Type | Objet Kubernetes de configuration (clé/valeur) |
| Groupe API | v1 (core)
|
| Consommation | Variable d'environnement · argument de commande · volume monté |
| Voir aussi | Kubernetes secrets · Kubernetes volumes |
Un ConfigMap est un objet Kubernetes qui stocke des données de configuration non confidentielles sous forme de paires clé/valeur. Il découple la configuration de l'image de conteneur : la même image peut ainsi être déployée dans plusieurs environnements en ne changeant que le ConfigMap associé.
Création et consultation
Un ConfigMap peut être créé de façon déclarative (fichier YAML) ou impérative :
# Création à partir d'un manifeste
kubectl create -f mon-configmap.yml
# Consultation
kubectl describe configmap mon-configmap
kubectl get configmap mon-configmap -o yaml
Exemple de manifeste :
apiVersion: v1
kind: ConfigMap
metadata:
name: mon-configmap
data:
key1: valeur1
key2: valeur2
Consommation dans un Pod
Trois modes de consommation possibles :
- Variable d'environnement — chaque clé du ConfigMap devient une variable dans le conteneur.
- Argument de ligne de commande — la valeur est injectée dans
argsoucommandvia une variable d'environnement. - Volume monté — chaque clé devient un fichier dans un répertoire du conteneur, la valeur étant le contenu du fichier.
apiVersion: v1
kind: Pod
metadata:
name: env-pod
spec:
containers:
- name: app
image: busybox
command: ["sh", "-c", "env"]
envFrom:
- configMapRef:
name: mon-configmap
Après création du Pod, les valeurs injectées sont visibles dans les logs :
kubectl create -f env-pod.yml
kubectl logs env-pod
Pour un montage en volume, chaque clé apparaît comme un fichier distinct :
kubectl create -f volume-pod.yml
kubectl exec volume-pod -- ls /etc/config/configmap
kubectl exec volume-pod -- cat /etc/config/configmap/key1
Et pour les données sensibles ?
Le ConfigMap n'est pas adapté à une donnée confidentielle (mot de passe, token, certificat) : son contenu n'est ni chiffré ni masqué, il apparaît en clair dans kubectl get configmap -o yaml. L'objet équivalent pour ce cas d'usage est le Secret natif — mêmes principes de consommation (variable d'environnement ou volume), mais avec un encodage base64 (qui n'est pas du chiffrement) et un stockage à part dans etcd.
Création rapide d'un Secret générique à partir de valeurs déjà encodées :
# Encoder une valeur en base64 (ne remplace pas un vrai chiffrement)
echo -n '<votre-valeur>' | base64
apiVersion: v1
kind: Secret
metadata:
name: mon-secret
type: Opaque
data:
cle1: <valeur-encodee-en-base64>
cle2: <valeur-encodee-en-base64>
kubectl create -f mon-secret.yml
Une fois monté en volume, un Secret se consulte comme un ConfigMap :
kubectl exec volume-pod -- ls /etc/config/secret
kubectl exec volume-pod -- cat /etc/config/secret/secretkey1
Pour la gestion avancée des Secrets natifs (chiffrement au repos, rotation, intégration à un coffre-fort externe type Vault), voir Kubernetes secrets.
Cas pratique : authentification basique nginx (htpasswd)
Exemple courant : protéger un serveur nginx par un fichier .htpasswd monté depuis un Secret.
# Générer le fichier htpasswd (mot de passe saisi de façon interactive)
htpasswd -c .htpasswd <utilisateur>
# Créer le Secret à partir du fichier généré
kubectl create secret generic nginx-htpasswd --from-file .htpasswd
# Nettoyer le fichier local une fois le Secret créé
rm .htpasswd
Le Pod nginx référence ensuite ce Secret ainsi qu'un ConfigMap de configuration nginx (montés tous deux en volumes), puis on vérifie que l'authentification est bien exigée :
kubectl get cm
kubectl describe cm nginx-config
kubectl apply -f pod.yml
kubectl get pods -o wide
# Sans identifiants : doit échouer
kubectl exec busybox -- curl <IP_POD_NGINX>
# Avec identifiants : doit réussir
kubectl exec busybox -- curl -u <utilisateur>:<votre-mot-de-passe> <IP_POD_NGINX>