Les bonnes pratiques du cloud-native (12 facteurs) recommandent de ne jamais hardcoder la configuration dans l’image conteneur. La même image doit pouvoir s’exécuter en développement, test, staging et production avec des paramètres différents. Kubernetes offre deux ressources : ConfigMap (données non sensibles) et Secret (données sensibles, encodées en base64).

• ConfigMap – variables d’environnement, paramètres d’application, fichiers de configuration (nginx.conf, application.properties).
• Secret – mots de passe, tokens OAuth, clés SSH, certificats TLS.
• Injection – on peut les exposer comme variables d’environnement ou monter en tant que fichiers (volumes).

ISOSET enseigne ces bonnes pratiques dès les premiers modules Kubernetes.

Une ConfigMap stocke des paires clé-valeur ou des fichiers entiers. Elle peut être créée via YAML ou via la ligne de commande. Exemple : configuration d’un backend (URL de base, nombre max de connexions).

# ConfigMap YAML
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgresql://db.prod.svc:5432"
  log_level: "info"
  app.properties: |
    mode=production
    timeout=30s

# Pod utilisant ConfigMap comme variables d’env
env:
  - name: DB_URL
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: database_url

# Volume monté à partir d’une ConfigMap
volumes:
- name: config-volume
  configMap:
    name: app-config
containers:
- volumeMounts:
  - name: config-volume
    mountPath: /etc/config

ISOSET forme à la gestion centralisée des configurations multi-environnements avec ConfigMap.

Les Secrets sont similaires aux ConfigMaps, mais destinés aux données sensibles. Les valeurs sont encodées en base64 (pas chiffrées par défaut, attention). Kubernetes peut les chiffrer au repos (encryption at rest) et restreindre leur accès via RBAC.

• Création – `kubectl create secret generic db-secret –from-literal=password=monMotDePasse` ou via YAML avec valeurs base64.
• Types de Secrets – Opaque (générique), docker-registry (accès registre), tls (certificats), service-account-token (automatique).
• Bonnes pratiques – ne pas versionner les Secrets en clair dans Git. Utiliser des outils comme Sealed Secrets, External Secrets Operator, ou Vault.

# Secret YAML (base64)
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: c3VwZXJTZWNyZXQ=   # echo -n "superSecret" | base64

# Montage de Secret en fichier
volumes:
- name: secret-volume
  secret:
    secretName: db-secret
containers:
- volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets
    readOnly: true

ISOSET forme aux bonnes pratiques de gestion des secrets en Kubernetes : chiffrement, rotation, intégration avec Vault.

• Encodage – ConfigMap : clair. Secret : base64 (pas du chiffrement).
• Taille limite – 1 MiB pour chacun (par défaut).
• Mise à jour – modifier un ConfigMap/Secret met à jour les volumes montés (mais pas les variables d’environnement déjà injectées – nécessite redémarrage du Pod).
• Accès RBAC – on peut restreindre l’accès aux Secrets plus strictement qu’aux ConfigMaps.
• Logging – les Secrets ne sont pas affichés dans `kubectl describe` (leurs valeurs sont masquées).

• ConfigMap pour configuration applicative – niveau de log, URL de service externe, flags de fonctionnalités.
• ConfigMap pour fichiers de config entiers – nginx.conf, prometheus.yml, fluentd.conf.
• Secret pour base de données – mot de passe PostgreSQL, utilisateur.
• Secret pour clé API externe – token Stripe, clé OpenAI.
• Secret TLS – certificats pour Ingress.

• Chiffrement au repos (etcd) – configurer `EncryptionConfiguration` dans l’API server.
• Ne pas versionner les Secrets en clair – utiliser Sealed Secrets, SOPS, ou Helm secrets.
• External Secrets Operator (ESO) – synchronise les secrets depuis un gestionnaire externe (Vault, AWS Secrets Manager, Azure Key Vault).
• RBAC minimal – donner l’accès aux Secrets uniquement aux services et utilisateurs qui en ont besoin.
• Audit – activer les logs d’accès aux Secrets pour détecter les accès anormaux.

# SealedSecret (exemple – stockable dans Git)
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: mysecret
spec:
  encryptedData:
    password: AgBy3i... (chiffré avec clé publique)

ISOSET propose des modules avancés sur la gestion des secrets en production avec ESO et Vault.

Avec GitOps (ArgoCD, Flux), la configuration est versionnée dans Git. Les ConfigMaps sont sans risque. Pour les Secrets, on utilise Sealed Secrets ou un dépôt séparé avec accès restreint. ISOSET forme à ces pratiques modernes pour des déploiements sécurisés.

Les témoignages d’anciens élèves d’ISOSET confirment l’importance de ces concepts : *« Avant la formation, je hardcodais les mots de passe dans les images. Maintenant j’utilise des Secrets avec External Secrets Operator. Mes pipelines sont beaucoup plus sécurisés. »*