Comment verrouiller l’UID/GID du conteneur et la propriété des volumes avant les mises à jour d’applications auto-hébergées

Les mises à jour d’applications auto-hébergées sont moins susceptibles de créer des fichiers appartenant à root lorsque le déploiement fixe un contrat utilisateur numérique et vérifie la propriété des volumes avant de remplacer le conteneur.

La mesure préventive consiste à ne plus considérer le nom d’utilisateur interne de l’image comme une identité de stockage stable. Notez l’UID et le GID effectifs qui écrivent les données persistantes, associez-les aux répertoires hôtes ou aux volumes nommés, conservez les paramètres PUID/PGID ou d’espace de noms utilisateur, puis testez la nouvelle image sur un petit chemin accessible en écriture avant le déploiement complet. Ainsi, une mise à jour d’image ne pourra pas modifier silencieusement le propriétaire numérique de la configuration, des téléversements, des bases de données ou des métadonnées multimédias.

Notez l’UID et le GID numériques avant la mise à jour

Relevez l’utilisateur du processus en cours d’exécution, le groupe principal, les groupes supplémentaires ainsi que la propriété numérique de fichiers représentatifs dans chaque point de montage accessible en écriture. Enregistrez le condensé ou la version de l’image avec cette référence de propriété.

Les recommandations de Docker concernant la création d’images indiquent que des identifiants explicites évitent les dérives entre compilations, car les utilisateurs d’image attribués automatiquement peuvent recevoir des identifiants numériques différents selon les reconstructions.

Notez les nombres, et pas uniquement des noms tels que app ou media. Une nouvelle image peut réutiliser le même nom d’utilisateur tout en modifiant son UID, tandis que les fichiers hôtes enregistrent une propriété numérique.

Fixez l’utilisateur d’exécution dans le contrat de déploiement

Lorsque l’image prend en charge l’exécution directe avec un compte non root, indiquez explicitement l’utilisateur et le groupe prévus dans Compose ou dans la configuration d’exécution. Si l’image nécessite une phase d’initialisation avec root, documentez le processus ultérieur qui écrit réellement les données persistantes.

La spécification des images Open Container définit User comme valeur d’exécution par défaut, ce qui signifie qu’une image modifiée peut changer l’identité d’exécution, sauf si le déploiement la remplace ou la vérifie volontairement.

N’imposez pas un UID non root arbitraire aux images qui nécessitent un modèle d’initialisation pris en charge. Le contrat doit respecter la conception documentée de l’application tout en garantissant que le propriétaire des fichiers persistants reste prévisible.

Alignez PUID et PGID sur la propriété de l’hôte

Pour les images qui exposent les variables PUID et PGID, fixez ces valeurs dans la configuration Compose ou d’environnement versionnée et assurez-vous que les répertoires de volumes côté hôte appartiennent au compte de service correspondant.

LinuxServer explique que PUID associe les écritures du conteneur afin que les fichiers créés dans les volumes associés restent gérables en dehors du conteneur.

Avant la mise à jour, comparez les identifiants configurés avec la commande id sur l’hôte et avec la propriété des fichiers existants. Ne copiez pas aveuglément une valeur d’exemple telle que 1000 sur un serveur où cet identifiant appartient à une autre personne ou à un autre service.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Tenez compte des espaces de noms utilisateur et du mappage rootless

Docker ou Podman rootless peut faire apparaître un processus comme root dans le conteneur tout en le mappant vers un UID non root sur l’hôte. Notez le mode d’espace de noms ainsi que la configuration des UID/GID secondaires avant d’interpréter les changements de propriété.

Les options d’exécution de Podman montrent que keep-id préserve le mappage utilisateur lorsqu’un conteneur doit accéder de manière prévisible aux fichiers montés depuis l’hôte.

Ne « corrigez » pas un propriétaire qui semble être root dans le conteneur avant d’avoir inspecté l’identifiant numérique côté hôte. Le root de l’espace de noms et le root de l’hôte ne représentent pas toujours la même identité.

Testez la nouvelle image sur un volume de test avant le déploiement

Avant de remplacer le conteneur de production, exécutez la nouvelle image avec l’UID/GID prévus et un répertoire temporaire qui reproduit les autorisations de production. Laissez l’initialisation au démarrage créer un fichier et un répertoire, puis inspectez leur propriété côté hôte.

Le guide de Red Hat consacré au dépannage des volumes rootless montre que la propriété hôte suit le mappage des UID, plutôt que le nom d’utilisateur affiché dans le conteneur, qui ne constitue pas à lui seul une preuve suffisante.

Si le test crée des fichiers inattendus appartenant à root ou remappés, interrompez le déploiement et comparez l’utilisateur de l’image, le point d’entrée, l’espace de noms et les paramètres de montage. Cette approche est bien plus sûre que de découvrir le changement après qu’une migration récursive au démarrage a modifié toute une arborescence de photos ou de base de données.

Vérifiez les groupes supplémentaires et les chemins accessibles en écriture

Certaines applications ont besoin d’un UID de service principal ainsi que d’un accès via un groupe partagé pour les médias, les téléchargements ou les périphériques. Notez ces identifiants de groupe et testez tous les chemins accessibles en écriture, pas uniquement le répertoire de configuration.

Kubernetes utilise des contrôles explicites runAsUser et runAsGroup, illustrant le même principe de propriété Linux, même en dehors d’un simple déploiement Docker Compose.

La politique de mise à jour est complète lorsque la nouvelle image crée des fichiers avec la propriété hôte attendue sur chaque chemin persistant et résiste à la recréation d’un conteneur. L’article ZimaSpace associé sur les fichiers appartenant à root après une mise à jour d’image constitue la procédure de récupération si un déploiement a déjà produit des données appartenant à root.