Liste de contrôle du mappage des utilisateurs et des groupes de conteneurs pour les partages NAS

L’approche sûre consiste à traiter une vérification de correspondance des identités numériques, depuis l’export NAS jusqu’au montage sur l’hôte et au processus du conteneur en cours d’exécution, comme une séquence d’étapes observables, et non comme une commande unique.

Sur un hôte de conteneurs Linux utilisant des partages NAS reposant sur SMB ou NFS, le risque concret est qu’un conteneur puisse voir un chemin monté depuis le NAS, mais que les lectures ou écritures échouent avec des erreurs d’autorisation. Consignez l’identité actuelle et le point de récupération, commencez par le test différenciateur le moins invasif, interprétez les résultats positifs et négatifs avant de modifier une autre variable, et arrêtez-vous si le stockage devient instable ou si la seule copie récupérable risque d’être exposée. Le processus ci-dessous ne se termine qu’une fois la charge de travail d’origine exécutée avec succès ou lorsque les éléments disponibles atteignent une limite nécessitant une escalade.

Identifier l’identité réelle du processus du conteneur

Examinez la documentation de l’image, le paramètre Compose user, les variables d’environnement, le comportement de l’entrypoint, ainsi que l’UID, le GID et les groupes supplémentaires du processus applicatif en cours d’exécution. Les variables nommées PUID et PGID sont des conventions propres aux images, et non des fonctionnalités universelles de Docker ; vérifiez donc que cette image les prend en charge.

Un cas traité par la communauté LinuxServer concernant un problème d’autorisations du conteneur lié à PUID et PGID montre que des valeurs PUID et PGID apparemment correctes peuvent malgré tout laisser un montage bind inaccessible. Utilisez ce cas comme rappel d’inspecter le processus et le montage en cours d’exécution, et non comme preuve que toutes les images appliquent la même logique d’initialisation.

Consignez les valeurs numériques avec id dans le conteneur et sur l’hôte. Arrêtez-vous si l’application s’exécute en tant que root uniquement parce que les autorisations ont précédemment échoué ; l’accès root masque le défaut de correspondance et augmente l’impact d’un service compromis.

Suivre la propriété du NAS jusqu’au montage sur l’hôte

Sur le NAS, examinez le propriétaire numérique, le groupe, le mode, l’ACL et l’ACL par défaut du répertoire cible. Sur l’hôte du conteneur, examinez les mêmes objets montés et comparez les valeurs numériques. Si les noms diffèrent mais que les nombres correspondent, les libellés sont purement esthétiques ; si les nombres diffèrent, le chemin d’autorisation est réellement différent.

Pour NFS, incluez les options d’exportation, la version de NFS, la correspondance des identifiants, la restriction root squashing et l’identité de montage du client. Pour SMB, incluez les identifiants de montage, l’identité mappée côté serveur, les options de présentation uid ou gid, ainsi que l’utilisation éventuelle des extensions Unix ou de la traduction des ACL.

Ne modifiez pas simultanément les ACL du serveur et les options de montage du client. L’étape est validée lorsqu’un fichier de test possède un propriétaire numérique connu et que l’hôte observe une correspondance stable après démontage, remontage et redémarrage.

Tester le montage bind et les groupes supplémentaires

Vérifiez que le chemin source du conteneur correspond bien au montage attendu sur l’hôte, et non à un répertoire local vide créé avant le montage du partage réseau. Inspectez le montage d’exécution, puis testez l’énumération, la lecture, la création, le renommage et la suppression en tant qu’utilisateur de l’application dans un sous-répertoire jetable.

Un cas documenté sur Server Fault concerne une incompatibilité d’autorisations ACL avec NFS, même lorsque le propriétaire et les entrées ACL semblent correspondre, ce qui montre pourquoi le masque ACL, la correspondance côté serveur et l’identité effective doivent tous être examinés. Capturez la sortie de getfacl pour le répertoire et le fichier créé.

Si l’accès par groupe est prévu, ajoutez le groupe numérique supplémentaire pris en charge et recréez le conteneur, car les groupes des processus sont fixés au démarrage. Utilisez le guide ZimaSpace sur le diagnostic d’un chemin vide dans un conteneur lorsque l’application démarre sur un chemin vide ; il s’agit d’un problème d’ordre de montage, et non d’un problème d’ACL.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Appliquer la correction d’identité la plus limitée et retester

Privilégiez l’alignement de l’UID, du GID ou du groupe supplémentaire pris en charge par l’application sur la politique du NAS. Utilisez un groupe partagé et une ACL héritée lorsque plusieurs services collaborent. Évitez les autorisations accessibles en écriture à tous, les modifications récursives de propriété sur des jeux de données sans rapport et les conteneurs privilégiés comme solutions de facilité.

Recréez le conteneur, remontez le partage si les options de correspondance ont changé, puis répétez les mêmes opérations. Redémarrez l’hôte une fois pour vérifier que l’ordre de montage et l’identité numérique sont conservés au démarrage. Vérifiez que les fichiers nouvellement créés restent modifiables par les utilisateurs humains prévus sans accorder au conteneur des droits inutiles.

Terminez la checklist lorsque l’application exécute correctement sa charge de travail d’origine, que les opérations refusées le restent et que la propriété demeure stable après un redémarrage. Demandez une escalade si les espaces de noms utilisateur, les correspondances rootless ou les services d’identité du NAS réécrivent les identifiants d’une manière que l’image choisie ne peut pas prendre en charge.