Votre application Docker pourra-t-elle écrire dans ses données ? Liste de vérification des permissions des volumes

Pourquoi un conteneur en cours d’exécution peut-il quand même échouer à écrire ?

Un conteneur peut se lancer normalement alors que son application ne parvient pas à créer, modifier ou supprimer des fichiers dans un répertoire de données monté. Le démarrage du conteneur prouve que son processus peut s’exécuter ; il ne prouve pas que ce processus dispose des accès dont l’application a besoin.

Pour qu’une écriture aboutisse, l’identité effective du processus de l’application doit disposer des accès appropriés au chemin monté. Un montage en lecture seule, un répertoire parent inaccessible, une ACL, une règle SELinux ou un mappage d’espace de noms utilisateur peuvent également bloquer l’accès. Diagnostiquez le chemin et l’opération concernés avant de modifier les permissions.

• Notez le message d’erreur de l’application ainsi que le fichier ou le répertoire exact concerné.
• Déterminez si l’échec porte sur une opération particulière, comme la création d’un fichier, ou sur tous les accès au répertoire de données.
• Évitez de modifier les permissions de manière récursive avant d’avoir identifié l’identité et la règle d’accès à l’origine du problème.

Identifiez l’identité du processus et le chemin monté

Commencez par vérifier la configuration du conteneur et les montages signalés par Docker. Pour un conteneur nommé myapp, exécutez :

docker inspect --format '{{json .Mounts}}' myapp

Examinez la source du montage, sa destination, son type et son paramètre de lecture/écriture. Un montage lié pointe vers un chemin de l’hôte ; un volume nommé a une source gérée par Docker. Vérifiez que la destination correspond au chemin que l’application tente réellement d’utiliser.

Vérifiez ensuite l’identité du conteneur avec docker exec myapp id. Considérez ce résultat comme un indice, et non comme une preuve définitive de l’identité du processus de l’application : un point d’entrée peut démarrer avec une identité donnée, puis abandonner ses privilèges avant de lancer l’application. Consultez la documentation de l’image ou de l’application pour connaître l’utilisateur d’exécution prévu et, dans la mesure du possible, vérifiez directement le processus en cours.

Comparez les identifiants numériques des utilisateurs et des groupes, et pas seulement leurs noms. Sur un montage lié Linux classique sans remappage des utilisateurs, la propriété est déterminée par les identifiants numériques sur l’hôte comme dans le conteneur. Un même nom d’utilisateur dans deux images peut correspondre à des identifiants numériques différents.

• Confirmez le nom du conteneur, la destination du montage et son chemin source sur l’hôte ou le nom du volume.
• Trouvez l’utilisateur et les groupes effectifs du processus de l’application, y compris tout abandon de privilèges après le démarrage.
• Notez les identifiants numériques. Les noms d’utilisateur ne suffisent pas pour comparer la propriété de manière fiable.

Vérifiez la propriété, les bits de permission et les contrôles de l’hôte

Sur un hôte Linux, examinez la source du montage lié en affichant la propriété et les permissions sous forme numérique. Remplacez /srv/myapp/data par le chemin réel sur l’hôte :

ls -ln /srv/myapp/data

stat -c '%u:%g %a %n' /srv/myapp/data

Vérifiez le répertoire ainsi que ses répertoires parents. Le processus doit disposer des accès appropriés tout au long du chemin ; un répertoire final qui semble accessible en écriture ne suffit pas s’il ne peut pas traverser un répertoire parent. Si l’outil est disponible, namei -l /srv/myapp/data peut aider à afficher les permissions de chaque élément du chemin.

Si les accès ne correspondent toujours pas aux indications données par la propriété et les bits de permission classiques, vérifiez les ACL avec getfacl et, sur les systèmes qui utilisent SELinux, examinez le contexte des fichiers avec ls -Z. Les contrôles pertinents sur l’hôte et les mappages d’identités dépendent du déploiement. Docker sans privilèges et le remappage des espaces de noms utilisateur peuvent faire différer les identifiants sur l’hôte de ceux visibles dans le conteneur.

• Comparez l’UID et les groupes du processus au propriétaire, au groupe et aux bits de permission du répertoire.
• Vérifiez les permissions de traversée des répertoires parents ainsi que les accès au répertoire final.
• Si les vérifications ordinaires de propriété ne suffisent pas à expliquer le résultat, examinez les ACL, le contexte SELinux et les mappages d’espaces de noms utilisateur ou de Docker sans privilèges.

Testez les opérations dont l’application a réellement besoin

Une liste de permissions ne remplace pas un test d’écriture. Vérifiez d’abord si Docker a monté le chemin en lecture seule. Un montage en lecture seule peut empêcher volontairement l’enregistrement, même si le répertoire sous-jacent semble accessible en écriture.

Effectuez le test avec l’identité effective de l’application, sur la destination montée, à l’aide d’un nom de fichier temporaire qui ne risque pas d’écraser des données de l’application. Si l’image contient un shell et que l’application s’exécute avec l’UID 1000 et le GID 1000, voici un exemple simple :

docker exec --user 1000:1000 myapp sh -c 'f=/data/.permission-test-$$; : > "$f" && rm "$f"'

Remplacez les identifiants et /data par les valeurs correspondant à votre déploiement. Ce test vérifie la création et la suppression du fichier ; il ne prouve pas que toutes les opérations de l’application fonctionneront. La modification d’un fichier existant, la création d’un sous-répertoire ou le renommage d’un fichier, par exemple, peuvent répondre à des exigences différentes. Le test peut également ne pas reproduire les groupes supplémentaires ni d’autres caractéristiques du processus de l’application ; interprétez donc son résultat en tenant compte de l’identité du processus et de l’erreur signalée par l’application.

Dans la mesure du possible, vérifiez aussi l’opération depuis l’application elle-même. Un test réussi dans un shell constitue un indice utile, mais l’application peut utiliser un autre chemin, une autre identité ou une autre opération.

• Utilisez un fichier temporaire dans le répertoire réellement monté et supprimez-le après le test.
• Ne testez la création ou la modification d’un répertoire que si l’application a besoin de ces opérations.
• Si le test réussit mais que l’application échoue toujours, vérifiez à nouveau le chemin réel, l’identité et les groupes de l’application, ainsi que l’erreur signalée.

Résolvez les incompatibilités d’UID et de GID sans utiliser chmod 777

Lorsque la propriété numérique ne correspond pas à l’identité de l’application, choisissez une correction adaptée au modèle d’accès prévu. Ne partez pas du principe qu’il est sans risque de modifier tous les fichiers en leur attribuant un UID supposé : confirmez d’abord l’identité d’exécution indiquée dans la documentation de l’application et vérifiez si d’autres services ou administrateurs doivent y accéder.

Pour un répertoire destiné à être partagé, mettez en place un groupe incluant les identités de processus concernées et n’accordez que les accès de groupe nécessaires. Le bit setgid peut aider les nouveaux éléments à hériter du groupe du répertoire, mais le seul accès en écriture de groupe sur les fichiers existants ne garantit pas que les futurs fichiers resteront accessibles au groupe. L’umask de l’application et d’éventuelles ACL par défaut peuvent influer sur les nouveaux fichiers.

Un chmod 777 appliqué partout accorde des accès étendus et ne constitue pas une solution fiable. Il ne résout pas, par exemple, un montage en lecture seule ou une restriction SELinux. Privilégiez la modification la plus limitée de la propriété, du groupe, des ACL ou du montage qui répond à la cause vérifiée, et conservez une sauvegarde avant toute modification importante de propriété.

• Si seul le propriétaire est incorrect, confirmez l’UID prévu et la portée de la modification avant de changer la propriété.
• Si plusieurs processus doivent accéder au répertoire, utilisez un groupe convenu et vérifiez l’appartenance au groupe, le comportement du bit setgid, l’umask et les ACL par défaut.
• Si le montage est en lecture seule, corrigez sa configuration uniquement si l’application est censée y écrire.
• N’utilisez pas chmod 777 comme solution générale de dépannage.

Revérifiez les permissions après un changement d’image, d’hôte ou de méthode de déploiement

Un déploiement qui fonctionnait auparavant peut échouer après une modification de l’image ou de l’hôte. La nouvelle image peut exécuter l’application avec une identité numérique différente, même si le nom du compte semble inchangé. Le transfert vers un autre hôte peut également modifier la propriété du répertoire de montage lié ou les contrôles d’accès de l’hôte.

Les volumes nommés nécessitent une vérification particulière. En règle générale, un volume nommé vide est initialisé à partir du répertoire de l’image lorsqu’il est monté à cet emplacement, sauf si la copie initiale est désactivée. Un volume existant n’est pas réinitialisé à la propriété du répertoire de l’image à chaque démarrage. Les pilotes de volume et les options de montage peuvent modifier le comportement : examinez donc le montage réel au lieu de vous fier à une hypothèse sur son initialisation.

Si vous utilisez Docker sans privilèges ou le remappage des espaces de noms utilisateur, tenez compte du mappage des identités lorsque vous comparez les identifiants du conteneur et de l’hôte. N’appliquez pas de chown sur l’hôte en vous fondant uniquement sur un UID du conteneur sans comprendre le mappage de cet UID.

• Avant de mettre une image à jour, vérifiez si l’utilisateur d’exécution de l’application ou ses chemins de données ont changé.
• Avant une migration vers un autre hôte, notez le chemin source, la propriété numérique, les ACL, le contexte de sécurité et la configuration du montage.
• Pour les volumes nommés, distinguez un volume nouvellement créé d’un volume existant et vérifiez son contenu et sa propriété actuels.
• Dans les configurations sans privilèges ou avec remappage, vérifiez le mappage avant de modifier la propriété sur l’hôte.

Documentez les accès attendus et vérifiez-les après une migration

Conservez une courte fiche indiquant le chemin des données, le type de volume, l’UID et les groupes de l’application, les opérations de lecture et d’écriture nécessaires, ainsi que les paramètres délibérés d’ACL ou de sécurité de l’hôte. Précisez si le montage est en lecture seule et si un remappage d’identités est utilisé. Cela facilitera la vérification de la prochaine mise à jour ou migration.

Après une migration, une mise à jour d’image ou un changement de déploiement, répétez l’inspection et le test. Vérifiez que l’application peut effectuer les opérations dont elle dépend, et pas seulement que le conteneur démarre. Conservez une copie récupérable des données importantes avant de modifier leur propriété ou leurs contrôles d’accès.

Un déploiement géré peut réduire la quantité de travail d’infrastructure prise en charge par une équipe, mais il ne supprime pas la nécessité de prendre des décisions éclairées concernant les données, les accès et la récupération. Airbip propose le déploiement géré d’applications du catalogue exécutées sous forme de charges de travail Docker sur les serveurs cloud Airbip, avec la gestion du cycle de vie des services et des sauvegardes configurables quotidiennes, hebdomadaires et mensuelles. Consultez le site Airbip en vigueur pour connaître les offres et conditions actuelles, et vérifiez qu’une approche gérée répond à vos exigences opérationnelles et à vos besoins en matière de données.

• Documentez les identités numériques, les détails des montages, les opérations prévues et les éventuels contrôles non standards de l’hôte.
• Répétez le véritable test d’écriture après une migration ou une mise à jour, et examinez tout échec avant de vous fier au déploiement.
• Définissez clairement les responsabilités liées à la propriété et à la récupération des données, que vous gériez vous-même le serveur ou que vous utilisiez un hébergement géré.