Utilisation des ConfigMaps et Secrets comme variables ou volumes

Rendre la configuration accessible : les deux voies principales

Nous avons vu comment stocker la configuration non sensible dans les ConfigMaps et les données sensibles dans les Secrets. L'étape suivante, tout aussi cruciale, est de rendre ces données accessibles aux processus qui s'exécutent à l'intérieur de nos conteneurs. Comment notre application peut-elle lire l'URL de la base de données stockée dans un ConfigMap ou utiliser la clé API stockée dans un Secret ?

Kubernetes offre principalement deux mécanismes distincts pour consommer les données des ConfigMaps et des Secrets à l'intérieur d'un Pod :

1. Injecter les données comme variables d'environnement : Les clés et valeurs du ConfigMap/Secret deviennent des variables d'environnement directement disponibles pour le processus du conteneur.
2. Monter les données comme fichiers dans un volume : Les clés et valeurs du ConfigMap/Secret sont exposées comme des fichiers dans le système de fichiers du conteneur, accessibles via un chemin de montage spécifique.

Le choix entre ces deux méthodes dépend de la nature des données, de la manière dont l'application s'attend à lire sa configuration, des exigences de mise à jour et des considérations de sécurité (en particulier pour les Secrets). Ce chapitre détaille ces deux approches, leurs variations et leurs implications.

Méthode 1 : Injection en tant que Variables d'Environnement

Cette méthode consiste à rendre les données d'un ConfigMap ou d'un Secret disponibles comme des variables d'environnement standard pour le processus principal du conteneur.

Sous-méthodes :

• Injecter une seule clé (`valueFrom`) : Vous pouvez sélectionner une clé spécifique d'un ConfigMap ou d'un Secret et l'assigner à une variable d'environnement nommée dans votre conteneur.

  # ... spec.containers[] ...
  env:
  # Depuis un ConfigMap
  - name: MY_APP_LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: mon-app-config # Nom du ConfigMap
        key: log.level       # Clé dans le ConfigMap
  # Depuis un Secret
  - name: API_SECRET_KEY
    valueFrom:
      secretKeyRef:
        name: mon-api-secret # Nom du Secret
        key: api.key       # Clé dans le Secret

  Ici, le conteneur aura les variables d'environnement `MY_APP_LOG_LEVEL` et `API_SECRET_KEY` avec les valeurs correspondantes.
• Injecter toutes les clés (`envFrom`) : Vous pouvez exposer toutes les paires clé-valeur d'un ConfigMap ou d'un Secret comme des variables d'environnement. Le nom de la clé dans l'objet devient le nom de la variable d'environnement.

  # ... spec.containers[] ...
  envFrom:
  - configMapRef:
      name: mon-app-config # Toutes les clés de ce ConfigMap deviennent des variables
  - secretRef:
      name: mon-db-credentials # Toutes les clés de ce Secret deviennent des variables

  Si `mon-db-credentials` contient les clés `username` et `password`, le conteneur aura les variables d'environnement `username` et `password`. Kubernetes ignorera les clés qui ne sont pas des noms de variables d'environnement valides (ex: contenant des points ou des tirets). Vous pouvez ajouter un préfixe à toutes les variables injectées via `envFrom` en utilisant le champ `prefix:`.

Avantages :

• Très simple pour l'application d'accéder aux valeurs (lecture de variables d'environnement standard).
• Convient bien aux paramètres simples et individuels (URLs, flags, identifiants).

Inconvénients :

• Pas de mise à jour dynamique : Les variables d'environnement sont définies au démarrage du conteneur. Si le ConfigMap ou le Secret source est modifié, les variables d'environnement des Pods existants ne sont pas mises à jour. Un redémarrage du Pod est nécessaire.
• Ne convient pas aux fichiers : Non adapté pour injecter des fichiers de configuration complets ou des données multilignes complexes.
• Sécurité des Secrets : Exposer des secrets comme variables d'environnement est généralement considéré comme moins sécurisé. Les variables d'environnement peuvent potentiellement fuiter via des logs d'erreur, des inspections du processus (ex: `/proc/[pid]/environ`), ou des commandes `exec` dans le conteneur.
• Encombrement de l'environnement : L'utilisation de `envFrom` peut potentiellement injecter un grand nombre de variables non désirées.

Méthode 2 : Montage en tant que Volume de Fichiers

Cette méthode rend les données d'un ConfigMap ou d'un Secret accessibles comme des fichiers à l'intérieur du système de fichiers du conteneur.

Fonctionnement :

1. Vous définissez un volume de type `configMap` ou `secret` dans la section `spec.volumes` de votre Pod.
2. Vous référencez le nom du ConfigMap ou du Secret à utiliser (`configMap.name` ou `secret.secretName`).
3. Vous définissez un `volumeMount` dans la section `spec.containers[].volumeMounts` pour monter ce volume dans un répertoire spécifique (`mountPath`) à l'intérieur du conteneur.

Sous-méthodes / Options :

• Monter toutes les clés comme fichiers : Par défaut, chaque clé dans le `data` (ou `stringData`) du ConfigMap/Secret devient un fichier dans le répertoire `mountPath`. Le nom du fichier est la clé, et le contenu du fichier est la valeur (décodée pour les Secrets).

  # ... spec ...
    containers:
    - name: mon-conteneur
      image: mon-image
      volumeMounts:
      - name: config-donnees # Doit correspondre au nom du volume
        mountPath: /etc/config/app # Répertoire cible dans le conteneur
      - name: secret-donnees
        mountPath: /etc/secrets/db
        readOnly: true # Recommandé pour les secrets
    volumes:
    - name: config-donnees
      configMap:
        name: mon-app-config # Nom du ConfigMap source
    - name: secret-donnees
      secret:
        secretName: mon-db-credentials # Nom du Secret source

  Le répertoire `/etc/config/app` contiendra des fichiers nommés d'après les clés de `mon-app-config`, et `/etc/secrets/db` contiendra des fichiers nommés d'après les clés de `mon-db-credentials`.
• Projeter des clés spécifiques (mapping) : Vous pouvez choisir quelles clés monter et spécifier le nom du fichier cible et potentiellement les permissions (`mode`) via le champ `items` dans la définition du volume.

  # ... spec ...
    volumes:
    - name: tls-certs
      secret:
        secretName: mon-tls-secret
        items:
        - key: tls.crt        # Clé dans le Secret
          path: certificate.pem # Nom du fichier dans le volume
        - key: tls.key
          path: private-key.pem
          mode: 0400          # Permissions spécifiques (lecture seule pour propriétaire)

  Ensuite, vous monteriez le volume `tls-certs` normalement via `volumeMounts`.
• Monter une seule clé via `subPath` : Si vous ne voulez monter qu'un seul "fichier" (une seule clé) d'un ConfigMap/Secret à un emplacement précis (fichier ou répertoire) sans masquer le contenu existant de ce répertoire, vous pouvez utiliser `subPath` dans le `volumeMount`.

  # ... spec.containers[] ...
      volumeMounts:
      - name: config-nginx
        mountPath: /etc/nginx/nginx.conf # Monter directement comme fichier
        subPath: nginx.conf           # Clé du ConfigMap à utiliser comme contenu

  Attention : L'utilisation de `subPath` empêche souvent la mise à jour dynamique du contenu si le ConfigMap/Secret source change.

Avantages :

• Idéal pour les fichiers de configuration, les scripts, les certificats, les clés.
• Permet de gérer des données multilignes ou binaires facilement.
• Mise à jour dynamique possible : Par défaut, les volumes montés depuis des ConfigMaps/Secrets sont périodiquement mis à jour par le Kubelet si l'objet source change. L'application doit être capable de détecter le changement du fichier et de le recharger pour en bénéficier sans redémarrage du Pod (ne fonctionne pas toujours avec `subPath`).
• Plus sécurisé pour les Secrets : Evite d'exposer les secrets dans l'environnement du processus. Permet de définir des permissions de fichiers restrictives (`readOnly: true`, `mode`).

Inconvénients :

• Nécessite que l'application soit conçue pour lire sa configuration depuis des fichiers.
• La mise à jour dynamique dépend du comportement de l'application (relecture des fichiers).

Synthèse : Quand utiliser quoi ?

Recommandations générales :

• Utilisez les volumes pour les fichiers de configuration et pour les Secrets chaque fois que possible.
• Utilisez les variables d'environnement pour des paramètres simples et non sensibles, ou lorsque l'application s'attend spécifiquement à lire des variables d'environnement.
• Préférez l'injection de clés spécifiques (`valueFrom`, `items` dans le volume) plutôt que l'injection de tout (`envFrom`, montage de volume complet) pour plus de clarté et le respect du principe de moindre privilège.

Conclusion : Flexibilité et contrôle de la configuration

Kubernetes offre une flexibilité remarquable pour fournir la configuration et les secrets nécessaires à vos applications conteneurisées, grâce aux ConfigMaps et aux Secrets combinés aux mécanismes d'injection par variables d'environnement ou par volumes.

Comprendre les avantages, les inconvénients et les implications de chaque méthode vous permet de choisir l'approche la plus adaptée à vos besoins spécifiques, en équilibrant la facilité d'utilisation, les exigences de mise à jour et les impératifs de sécurité. Une gestion efficace de la configuration est une étape clé vers la construction d'applications robustes et maintenables sur Kubernetes.