Les conteneurs Podman sans racine sont une fonctionnalité vraiment intéressante qui permet aux utilisateurs d'exécuter presque tous les conteneurs dans leur répertoire personnel sans nécessiter de privilèges supplémentaires.
Les conteneurs sans racine tirent parti de l'espace de noms d'utilisateur, comme je l'ai expliqué dans ce blog.
Parfois, l'espace de noms d'utilisateur et d'autres couches de sécurité du conteneur comme SELinux rendent plus difficile le partage de contenu à l'intérieur du conteneur. Nous avons vu de nombreux utilisateurs qui souhaitent partager des répertoires système dans leurs conteneurs mais échouent avec des erreurs d'autorisation. Ces répertoires sont généralement partagés via un accès de groupe, ce qui permet à l'utilisateur de lire/écrire du contenu dans les répertoires.
[ Vous pourriez également aimer : Conteneurs sans racine utilisant Podman ]
Par exemple, l'utilisateur peut avoir un répertoire /mnt/engineering sur leur système, qui appartient à root et le groupe eng , et avec des autorisations définies sur 770.
Prenons un exemple.
Ajoutez le eng groupe :
# groupadd eng Créez le répertoire de partage :
# mkdir /var/lib/mycontainers/ Modifier l'accès du groupe pour le répertoire :
# chown root:eng /var/lib/mycontainers/ Modifiez les autorisations afin que le groupe puisse écrire dans le répertoire :
# chmod 770 /mnt/engineering Modifiez le type SELinux du répertoire afin que les conteneurs puissent l'utiliser :
# chcon -t container_file_t /mnt/engineering Ensuite, regardons les permissions sur le répertoire :
# ls -lZ /mnt/engineering/ -d
drwxrwx---. 2 root eng unconfined_u:object_r:user_tmp_t:s0 40 Feb 9 07:24 /mnt/engineering/
Maintenant, l'utilisateur peut être ajouté au eng groupe :
$ grep eng /etc/group
Eng:x:14905:dwalsh
Connectez-vous au système et assurez-vous que l'utilisateur est dans le eng groupe :
$ id
uid=3267(dwalsh) gid=3267(dwalsh) groups=3267(dwalsh),10(wheel),14905(eng) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Assurez-vous que l'utilisateur peut lire/écrire du contenu dans le répertoire :
$ touch /mnt/engineering/test
$ ls -l /mnt/engineering/
total 0
-rw-------. 1 dwalsh dwalsh 0 Feb 9 07:36 test Exécutez maintenant un conteneur à l'aide de ce volume, mais le conteneur se voit refuser l'autorisation :
$ podman run --userns=keep-id -v /mnt/engineering/:/mnt/engineering ubi8 ls /mnt/engineering/
ls: cannot open directory '/mnt/engineering/': Permission denied Puisque nous savons que SELinux ne bloque pas puisque nous avons correctement défini l'étiquette, que s'est-il passé ?
Espace de noms d'utilisateur
Le problème est l'espace de noms d'utilisateur.
$ podman run --userns=keep-id -v /mnt/engineering/:/mnt/engineering ubi8 id
uid=3267(dwalsh) gid=3267(dwalsh) groups=3267(dwalsh)
Notez que le --userns=keep-id flag est utilisé pour s'assurer que l'UID à l'intérieur du conteneur n'est pas root mais l'UID normal de l'utilisateur. Remarquez ci-dessus que lorsque j'exécute le id commande en dehors du conteneur, mes groupes incluent le eng groupe, mais lorsque le conteneur est exécuté, le eng groupe ne s'affiche pas. Du point de vue de la sécurité, c'est une bonne chose car si les processus de conteneur s'échappaient, ils n'auraient pas accès aux répertoires auxquels j'ai un accès de groupe. Si les utilisateurs veulent accorder l'accès, ils ont un problème.
Le problème est qu'il est difficile d'accorder l'accès au conteneur à ces répertoires. Créer un eng le groupe à l'intérieur du conteneur ne correspondrait pas au eng groupe sur l'hôte car l'espace de noms d'utilisateur compense l'UID réel du groupe.
Heureusement, le runtime OCI crun prend en charge une fonction spéciale pour faire fuir ces groupes supplémentaires dans le conteneur. Cette capacité est couverte dans le podman run page de manuel :
man podman run
...
Note: if the user only has access rights via a group, accessing the de‐
vice from inside a rootless container will fail. The crun(1) runtime
offers a workaround for this by adding the option --annotation
run.oci.keep_original_groups=1.
Et expliqué plus en détail dans le crun page de manuel :
man crun
…
run.oci.keep_original_groups=1
If the annotation run.oci.keep_original_groups is present, then crun
will skip the setgroups syscall that is used to either set the addi‐
tional groups specified in the OCI configuration, or to reset the list
of additional groups if none is specified. Si je définis cette annotation, mon Podman sans racine a désormais accès au volume, comme indiqué ci-dessous :
$ podman run -ti --annotation run.oci.keep_original_groups=1 --userns=keep-id -v /mnt/engineering/:/mnt/engineering ubi8 ls /mnt/engineering/
-rw-------. 1 dwalsh dwalsh 0 Feb 9 12:36 test
Nous utilisons une annotation car la spécification OCI n'a actuellement aucun moyen de le dire au runtime OCI. Nous avons proposé de l'ajouter au cahier des charges. Pour le moment, aucun autre runtime OCI autre que crun peut gérer cela, y compris runc . Peut-être qu'à l'avenir, cette fonctionnalité sera ajoutée à l'OCI.
containers.conf
Si l'utilisateur souhaite que tous ses conteneurs partagent les groupes d'utilisateurs, il peut ajouter cette annotation au containers.conf dans leurs répertoires personnels.
$ cat ~/.config/containers/containers.conf
[containers]
annotations=["run.oci.keep_original_groups=1",] Désormais, même le Podman par défaut peut créer du contenu dans le volume, et les processus utilisateur en dehors du conteneur voient le contenu correct.
$ podman run -ti --userns=keep-id -v /mnt/engineering/:/mnt/engineering ubi8 touch /mnt/engineering/test2
$ ls -l /mnt/engineering/
total 0
-rw-------. 1 dwalsh dwalsh 0 Feb 9 07:36 test
-rw-r--r--. 1 dwalsh dwalsh 0 Feb 9 13:36 test2 [ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Conclusion
Le partage de contenu de l'hôte dans un conteneur via le montage de volume peut parfois être bloqué par diverses fonctionnalités de sécurité des conteneurs. Heureusement Podman et crun ont des fonctionnalités avancées pour permettre à des conteneurs spécifiques de partager ce contenu et containers.conf permet aux utilisateurs de configurer leur système sur tous les conteneurs pour accéder à ces volumes.