Erreurs de configuration des secrets Docker et comment les corriger : exemples pratiques

Introduction

Les secrets Docker offrent un moyen sécurisé de gérer les données sensibles telles que les mots de passe, les clés API et les certificats TLS dans les environnements conteneurisés. Cependant, des erreurs de configuration peuvent exposer ces secrets, interrompre des services ou entraîner des comportements inattendus. Cet article passe en revue les erreurs courantes de configuration des secrets Docker, des exemples pratiques, ainsi que la manière de les valider et de s'en remettre. En suivant les conseils donnés ici, vous éviterez les pièges de sécurité et réduirez le temps de dépannage.

Inventaire des versions et de l'environnement

Avant d'apporter toute modification, documentez les versions exactes et la topologie sur lesquelles vous travaillez. Cela garantit que les commandes et les configurations sont valides pour votre environnement.

Exemple d'inventaire :

Prérequis :

• Docker installé et en cours d'exécution avec le mode Swarm activé (docker swarm init sur un seul nœud est suffisant pour l'expérimentation).
• Familiarité de base avec les commandes Docker et la syntaxe YAML.
• Un éditeur de texte pour modifier les fichiers Compose.

Exécutez les commandes suivantes pour vérifier la disponibilité de Docker et de Swarm :

docker version
docker info --format '{{.Swarm.LocalNodeState}}'

Sortie attendue :

Client: Docker Engine - Community
 Version: 24.0.5
 ...
Server: Docker Engine - Community
 Engine:
 Version: 24.0.5
 ...
active

Si docker info ne renvoie pas active pour l'état de Swarm, initialisez Swarm avec docker swarm init.

Chemin de configuration sûr

Dans cette section, nous abordons trois erreurs de configuration courantes et leur implémentation sûre. Pour chaque erreur, nous fournissons un exemple pratique et l'approche corrigée.

Erreur 1 : Utiliser des variables d'environnement au lieu des secrets Docker

Une erreur courante consiste à transmettre des secrets via des variables d'environnement dans le fichier Compose ou en ligne de commande, ce qui les expose dans docker inspect et les listes de processus.

Approche incorrecte (extrait de fichier Compose) :

version: '3.8'
services:
  app:
    image: myapp:latest
    environment:
      - DB_PASSWORD=supersecret

Chemin sûr : Stockez le secret à l'aide de la gestion des secrets de Docker et référencez-le dans le service.

Tout d'abord, créez le secret à partir d'un fichier ou de l'entrée standard :

echo "supersecret" | docker secret create db_password -

Sortie attendue :

<secret_id>

Ensuite, mettez à jour le fichier Compose pour utiliser le secret :

version: '3.8'
services:
  app:
    image: myapp:latest
    secrets:
      - db_password
secrets:
  db_password:
    external: true

Déployez la pile et vérifiez que le secret est monté :

docker stack deploy -c docker-compose.yml mystack

Erreur 2 : Mauvaises permissions de fichiers sur les fichiers de secrets

Même avec les secrets Docker, les secrets sont montés sous forme de fichiers dans le conteneur à /run/secrets/<secret_name>. Par défaut, les permissions du fichier sont 0444 (lisible par tous les utilisateurs). Si votre application attend une permission différente ou si le secret est trop permissif, vous pouvez rencontrer des problèmes.

Exemple : Une application attend un fichier de secret avec les permissions 0600 et échoue parce qu'il est lisible par tous.

Docker ne permet pas de changer les permissions directement via Compose. Une solution de contournement sûre consiste à copier le secret vers un nouvel emplacement avec des permissions renforcées dans un script d'entrée ou à utiliser une commande qui ajuste les permissions.

Chemin sûr : Utilisez un petit script d'entrée qui copie le secret et définit les permissions avant de démarrer le processus principal.

Exemple de script d'entrée :

#!/bin/sh
set -e
if [ -f /run/secrets/db_password ]; then
  cp /run/secrets/db_password /tmp/db_password
  chmod 0600 /tmp/db_password
  export DB_PASSWORD_FILE=/tmp/db_password
fi
exec "$@"

Construisez l'image avec ce script, ou montez-le comme config, et définissez-le comme point d'entrée.

Erreur 3 : Secrets non mis à jour lors de la rotation

Lorsqu'un secret est renouvelé (par exemple, un mot de passe change), les services peuvent continuer à utiliser l'ancien secret jusqu'à ce qu'ils soient mis à jour. Si vous supprimez et recréez le secret avec le même nom, vous devez redémarrer ou mettre à jour le service pour qu'il prenne en compte la nouvelle valeur.

Erreur courante : Mettre à jour le secret mais pas le service.

Exemple :

docker secret rm db_password
echo "newsecret" | docker secret create db_password -
# Le service utilise toujours l'ancienne valeur du secret en mémoire

Chemin sûr : Après la rotation du secret, forcez une mise à jour du service pour remonter le secret :

docker service update --force mystack_app

Ou redéployez la pile avec le même fichier Compose après avoir mis à jour le secret externe.

Vérification et diagnostics

Après la configuration, vérifiez que les secrets sont correctement montés et accessibles.

Vérifiez le contenu du secret à l'intérieur du conteneur :

Trouvez l'ID du conteneur et lisez le fichier de secret :

docker ps --filter name=mystack_app --format '{{.ID}}'
docker exec <container_id> cat /run/secrets/db_password

Sortie attendue : la valeur du secret (par exemple, supersecret). Si la sortie est vide ou différente, le montage a échoué.

Inspectez le service pour confirmer l'attribution du secret :

docker service inspect mystack_app --pretty

Recherchez la section Secrets ; elle doit lister le nom du secret et la cible.

Vérifiez l'existence du secret :

docker secret ls

Sortie attendue :

ID                          NAME                DRIVER              CREATED             UPDATED
<id>                        db_password                             5 minutes ago       5 minutes ago

Tableau de diagnostic pour les symptômes courants :

Modes de défaillance et récupération

Comprendre comment les défaillances se manifestent aide à une récupération rapide. Voici les modes de défaillance courants et les étapes pour revenir en arrière ou récupérer.

Mode de défaillance 1 : Secret manquant au moment du déploiement

Si vous référencez dans Compose un secret qui n'existe pas, docker stack deploy échoue avec une erreur :

error: secret not found: db_password

Récupération : Créez d'abord le secret, puis redéployez.

Mode de défaillance 2 : Le service ne démarre pas en raison des permissions du fichier secret

Certaines applications refusent de démarrer si le fichier secret est lisible par tous. Le conteneur se termine immédiatement.

Récupération : Consultez les journaux du conteneur :

docker logs <container_id>

Si l'erreur concerne les permissions, appliquez la solution de contournement du point d'entrée décrite précédemment, puis mettez à jour le service.

Mode de défaillance 3 : Secrets exposés dans l'environnement

Si vous avez précédemment utilisé des variables d'environnement, elles peuvent encore être visibles dans la sortie de docker inspect :

docker inspect <container_id> --format '{{.Config.Env}}'

Récupération : Supprimez les variables d'environnement et passez aux secrets Docker. Redéployez la pile pour effacer l'ancien environnement.

Habitude de retour en arrière : Conservez toujours une sauvegarde de l'ancienne valeur du secret et de la version du fichier Compose. Pour revenir à un secret précédent, recréez le secret avec l'ancienne valeur et forcez la mise à jour du service. Pour un retour au niveau de la pile, utilisez docker stack deploy avec le fichier Compose précédent.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour la gestion régulière des secrets et le dépannage. Attribuez un seul responsable pour chaque élément et examinez la liste de contrôle mensuellement ou après tout changement d'infrastructure :

• [ ] Vérifiez que toutes les données sensibles sont stockées sous forme de secrets Docker, et non de variables d'environnement. Responsable : Ingénieur sécurité.
• [ ] Confirmez que les secrets sont créés avant le déploiement de la pile. Responsable : Ingénieur DevOps.
• [ ] Assurez-vous que les permissions des fichiers de secrets correspondent aux exigences de l'application ; ajustez avec un point d'entrée si nécessaire. Responsable : Développeur d'applications.
• [ ] Après la rotation des secrets, forcez la mise à jour des services et vérifiez que la nouvelle valeur est montée. Responsable : Responsable des opérations.
• [ ] Auditez régulièrement docker secret ls et supprimez les secrets inutilisés. Responsable : Ingénieur sécurité (hebdomadaire).
• [ ] Testez l'accès aux secrets dans les conteneurs dans le cadre de l'IC ou de contrôles manuels. Responsable : Ingénieur QA.
• [ ] Documentez les procédures de rotation des secrets dans votre runbook. Responsable : Rédacteur technique.
• [ ] Utilisez docker service inspect pour examiner les montages de secrets avant le déploiement en production. Responsable : Gestionnaire de version.
• [ ] Conservez des sauvegardes des valeurs de secrets actuelles et précédentes dans un coffre-fort sécurisé en dehors de Docker. Responsable : Ingénieur sécurité.

Pièges courants et comment les éviter

Au-delà des trois principales erreurs abordées, voici d'autres pièges qui font souvent trébucher les équipes :

Piège 1 : Coder en dur des secrets dans les images

Pourquoi cela arrive : Les développeurs intègrent parfois des secrets dans l'image lors de la construction pour plus de commodité, par exemple dans une instruction ENV du Dockerfile ou dans un fichier copié.

Comment l'éviter : Ne mettez jamais de secrets dans l'image. Utilisez les secrets Docker ou des variables d'environnement injectées à l'exécution. Analysez les images à la recherche de secrets avant de les pousser vers un registre (par exemple, avec docker scan ou un outil tiers).

Piège 2 : Ne pas limiter la portée des secrets

Pourquoi cela arrive : Dans Compose, vous pouvez accorder un secret à un service qui n'en a pas besoin parce qu'il est plus facile de réutiliser le même bloc de secrets pour plusieurs services.

Comment l'éviter : Accordez les secrets uniquement aux services qui en ont besoin. Utilisez des secrets distincts pour différents services même si la valeur est identique, afin de permettre une rotation et une révocation indépendantes.

Piège 3 : Utiliser docker secret en dehors de Swarm

Pourquoi cela arrive : Les développeurs peuvent essayer d'utiliser les secrets Docker avec un simple docker run ou Docker Compose en mode non-Swarm, sans se rendre compte que les secrets sont une fonctionnalité Swarm.

Comment l'éviter : Utilisez le mode Swarm (docker swarm init) même pour le développement local, ou utilisez des solutions alternatives de gestion des secrets pour les environnements non-Swarm (par exemple, des variables d'environnement avec prudence, ou des volumes montés avec des permissions restreintes).

Piège 4 : Oublier de supprimer les secrets lorsqu'ils ne sont plus nécessaires

Pourquoi cela arrive : Les secrets s'accumulent au fil du temps, en particulier dans les environnements de test, et personne ne les nettoie.

Comment l'éviter : Incluez le nettoyage des secrets dans votre routine d'hygiène régulière. Utilisez docker secret rm pour supprimer les secrets inutilisés après avoir vérifié qu'aucun service en cours d'exécution n'en dépend.

Piège 5 : Noms de secrets incompatibles entre Compose et l'exécution

Pourquoi cela arrive : Des fautes de frappe ou des incohérences de nommage dans le fichier Compose ou lors de la création des secrets empêchent le montage des secrets.

Comment l'éviter : Utilisez une convention de nommage et validez avec docker service inspect après le déploiement. Envisagez d'utiliser des noms de secrets spécifiques à l'environnement (par exemple, db_password_prod vs db_password_dev) pour éviter une utilisation accidentelle entre environnements.

Conclusion

Les secrets Docker sont essentiels pour une configuration sécurisée, mais ils comportent des pièges. Dans cet article, nous avons abordé les erreurs courantes telles que l'utilisation de variables d'environnement, les permissions incorrectes et l'oubli de mettre à jour les services après la rotation. Nous avons fourni des exemples pratiques, des étapes de vérification et des conseils de récupération. En suivant le chemin de configuration sûr et en utilisant la liste de contrôle des opérations, vous pouvez minimiser les risques et garantir que vos conteneurs traitent correctement les secrets. Ensuite, appliquez ces pratiques dans un environnement pilote restreint pour valider votre configuration avant un déploiement plus large.