Exécuter chaque conteneur Docker dans une configuration d'espace de noms d'utilisateur spécifique

Question

Problème:

Je suis en train de monter un répertoire que le volume Docker de telle sorte, qu'un utilisateur qui est créé à l'intérieur d'un conteneur pourrait écrire dans un fichier dans ce volume. Et en même temps, le fichier doit être au moins lisible par mon utilisateur lape à l'extérieur du conteneur. Essentiellement, je dois remapper un UID d'utilisateur de l'espace de nom d'utilisateur de conteneur à un UID spécifique sur l'espace de noms d'utilisateur d'hôte.

Comment puis-je faire cela?

Je préférerais que les réponses:

• ne comportent pas de changer la manière dont le démon Docker est exécuté;
• et permet de configurer séparément l'espace de noms d'utilisateur de conteneur pour chaque conteneur;
• ne nécessite pas de reconstruire l'image;
• J'accepte la réponse qui montre une bonne solution en utilisant Access Control Lists ainsi;

Configuration:

Voici comment la situation peut être reproduite.

J'ai mon utilisateur Linux lape, affecté au groupe docker, donc je peut exécuter des conteneurs Docker sans être root.

lape@localhost ~ $ id 
uid=1000(lape) gid=1000(lape) groups=1000(lape),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),121(lpadmin),131(sambashare),999(docker) 

Dockerfile:

FROM alpine 
RUN apk add --update su-exec && rm -rf /var/cache/apk/* 

# I create a user inside the image which i want to be mapped to my `lape` 
RUN adduser -D -u 800 -g 801 insider 
VOLUME /data 

COPY ./entrypoint.sh /entrypoint.sh 
ENTRYPOINT ["sh", "/entrypoint.sh"] 

entrypoint.sh:

#!/bin/sh 
chmod 755 /data 
chown insider:insider /data 

# This will run as `insider`, and will touch a file to the shared volume 
# (the name of the file will be current timestamp) 
su-exec insider:insider sh -c 'touch /data/$(date +%s)' 

# Show permissions of created files 
ls -las /data 

Une fois que l'on construit avec:

docker build -t nstest 

je lance le conteneur:

docker run --rm -v $(pwd)/data:/data nstest 

La sortie ressemble à:

total 8 
4 drwxr-xr-x 2 insider insider  4096 Aug 26 08:44 . 
4 drwxr-xr-x 31 root  root   4096 Aug 26 08:44 .. 
0 -rw-r--r-- 1 insider insider   0 Aug 26 08:44 1503737079 

Ainsi, le fichier semble être créé en tant qu'utilisateur insider.

De mon hôte les autorisations se présentent comme suit:

lape@localhost ~ $ ls -las ./data 
total 8 
4 drwxr-xr-x 2 800 800 4096 Aug 26 09:44 . 
4 drwxrwxr-x 3 lape lape 4096 Aug 26 09:43 .. 
0 -rw-r--r-- 1 800 800 0 Aug 26 09:44 1503737079 

Ce qui indique que le fichier appartient à uid = 800 (qui est l'utilisateur insider qui n'existe même pas en dehors de l'espace de noms Docker).

choses que je déjà essayé:

1. I Tried spécifiant le paramètre --user-docker run, mais il semble qu'il peut ne carte quel utilisateur sur l'hôte est mis en correspondance avec uid = 0 (root) à l'intérieur du docker namespace, dans mon cas le insider n'est pas root. Donc ça n'a pas vraiment marché dans ce cas.

2. La seule manière dont j'ai réalisé insider (uid = 800) à partir de l'intérieur du récipient, être considéré comme lape (uid = 1000) de l'hôte, était en ajoutant --userns-remap="default" au script de démarrage dockerd, et en ajoutant dockremap:200:100000 aux fichiers /etc/subuid et /etc/subgid comme suggéré dans documentation for --userns-remap. Par coïncidence cela a fonctionné pour moi, mais ce n'est pas une solution suffisante, parce que:

   • il faut reconfigurer la façon dont fonctionne le démon Docker;
   • nécessite de faire un peu d'arithmétique sur les ID utilisateur: '200 = 1000 - 800', où 1000 est l'UID mon utilisateur sur l'hôte, et 800 l'UID est de l'utilisateur insider;
   • qui ne fonctionnerait même pas si l'utilisateur initié devait avoir un UID plus élevé que mon utilisateur hôte;
   • il ne peut configurer que la manière dont les espaces de noms utilisateur sont mappés globalement, sans moyen d'avoir une configuration unique par conteneur;
   • cette solution fonctionne en quelque sorte mais c'est un peu trop moche pour une utilisation pratique.

Answer 1

Si vous le plus simple juste besoin d'un accès en lecture pour l'utilisateur, sera d'ajouter les autorisations de lecture pour tous les fichiers et sous-répertoires /data avec acls en dehors de docker.

Ajouter par défaut acl: setfacl -d -m u:lape:-rx /data.

Vous aurez également besoin de donner accès au répertoire lui-même: setfacl -m u:lape:-rx /data.

Y a-t-il des obstacles pour une telle solution?