ConfigMaps et Secrets dans Kubernetes : limites de taille, propagation des mises à jour et ce qu'un Secret ne protège pas

Ce que c'est

Un ConfigMap contient des données clé-valeur non confidentielles ; un Secret contient une petite quantité de données sensibles. Les deux sont consommés par les Pods sous forme de variables d'environnement, d'arguments de ligne de commande via ces variables, ou de fichiers dans un volume monté. La documentation des ConfigMaps (citée) indique qu'un ConfigMap n'est pas conçu pour contenir de grandes quantités de données et que ses données ne peuvent pas dépasser 1 Mio ; la documentation des Secrets (citée) fixe la même limite de 1 Mio par Secret. Les deux objets peuvent être marqués immutable, après quoi leurs données ne peuvent plus être modifiées et le kubelet cesse de les surveiller.

Pourquoi c'est important

Deux propriétés sont régulièrement mal comprises. D'abord, la propagation des mises à jour : selon la documentation citée, un ConfigMap consommé dans un volume finit par se rafraîchir après la synchronisation périodique du kubelet, plus son délai de propagation de cache, alors que les ConfigMaps consommés sous forme de variables d'environnement ne sont pas mis à jour automatiquement et nécessitent un redémarrage du Pod, et un conteneur qui monte un ConfigMap via subPath ne reçoit jamais de mise à jour. Ensuite, la confidentialité : les Secrets sont, par défaut, stockés non chiffrés dans etcd ; quiconque dispose d'un accès à l'API peut récupérer ou modifier un Secret, quiconque dispose d'un accès à etcd peut le lire, et quiconque peut créer un Pod dans un espace de noms peut lire tous les Secrets de cet espace de noms par l'intermédiaire de ce Pod. Le base64 est un encodage, pas une protection.

Comment l'appliquer

• Garder dans l'image ou le manifeste la configuration qui change avec la version publiée, et ne placer dans les ConfigMaps que les valeurs propres à l'environnement ; versionner ailleurs les fichiers volumineux.
• Monter en volume sans subPath lorsque l'application peut relire les fichiers ; sinon, déclencher un déploiement lors d'un changement, par exemple en hachant le ConfigMap dans une annotation de Pod pour que le modèle de Deployment change.
• Suivre les étapes que liste la documentation des Secrets : activer le chiffrement au repos pour les Secrets, écrire des règles RBAC qui n'accordent get sur les Secrets qu'aux comptes de service qui en ont besoin, restreindre l'accès aux Secrets à des conteneurs précis, et envisager un magasin de secrets externe.
• Marquer immutable les ConfigMaps et Secrets liés à une version publiée et créer un nouvel objet par version ; cela réduit aussi la charge de surveillance du serveur API.
• Ne jamais afficher les objets Secret dans une sortie CI : kubectl get secret -o yaml montre la forme base64, trivialement décodable (kubectl describe masque les valeurs et n'affiche que leur taille).

Pièges

Portée de l'espace de noms : un Pod ne peut référencer que des Secrets se trouvant dans son propre espace de noms. La page de procédure sur les ConfigMaps (citée) indique qu'un ConfigMap ou une clé référencé qui n'existe pas empêche le Pod de démarrer, sauf si la référence est marquée optional ; le même champ optional existe pour les références de Secrets. Les variables d'environnement sont héritées par chaque processus enfant et tendent à se retrouver dans les sorties de diagnostic ; des fichiers aux permissions restrictives constituent la projection plus sûre pour les identifiants.