Autorisations utilisateur à l'intérieur et à l'extérieur des conteneurs LXC?

J'exécute certains services à l'intérieur des conteneurs Docker LXC sur mon serveur et je commence à faire des choses sérieuses avec eux.

Une chose que je ne sais pas, c'est comment fonctionnent les autorisations utilisateur à l'intérieur et à l'extérieur du conteneur. Si, par exemple, j'exécute MySQL dans un conteneur et que son répertoire de données est défini sur /data, qui est un volume Docker, comment les autorisations à l'intérieur et à l'extérieur du conteneur affectent-elles les stratégies d'accès?

De toute évidence, l'idée est d'exécuter MySQL comme son propre utilisateur dans le conteneur (c'est-à-dire mysql:mysql) et de lui donner des droits de lecture et d'écriture sur ce répertoire. Je suppose que ce serait assez simple, juste dans chmodle répertoire, etc. Mais comment cela fonctionne-t-il en dehors du conteneur? Maintenant que j'ai ce volume partagé Docker appelé «données», comment puis-je gérer le contrôle d'accès?

Je cherche spécifiquement à pouvoir exécuter un utilisateur non privilégié en dehors du conteneur Docker qui accédera périodiquement au volume partagé MySQL et sauvegardera les données.

Comment configurer les autorisations, les utilisateurs et les groupes pour qu'un utilisateur spécifique sur l'hôte puisse lire / écrire des fichiers et des dossiers dans le volume partagé Docker?

Depuis la sortie de 0,9 Docker a chuté LXCet utilise son propre environnement d'exécution, libcontainer. Votre question est un peu ancienne mais je suppose que ma réponse s'applique toujours à la version que vous utilisez.

Réponse rapide: Pour comprendre les autorisations des volumes, vous pouvez prendre l'analogie de mount --bind Host-Dir Container-Dir. Ainsi, pour répondre à vos besoins, vous pouvez utiliser toutes les méthodes traditionnelles de gestion des autorisations. Je suppose que l'ACL est ce dont vous avez besoin .

Réponse longue: Donc, comme dans votre exemple, nous avons un conteneur nommé dock avec un volume /data.

docker run -tid --name dock -v /usr/container/Databases/:/data \
    centos:latest /bin/bash

À l'intérieur du conteneur, notre serveur MySQL a été configuré pour utiliser le /datacomme répertoire de données. Nous avons donc nos bases de données à l' /dataintérieur du conteneur. Et en dehors du conteneur sur le système d'exploitation hôte, nous avons monté ce /datavolume à partir de /usr/container/Databases/et nous affectons un bob utilisateur normal pour prendre des sauvegardes des bases de données. À partir de la machine hôte, nous configurerons les ACL pour l'utilisateur bob .

useradd -u 3000 bob
usermod -R o=--- /usr/container/Databases/
setfacl -R -m u:bob:rwx /usr/container/Databases/
setfacl -R -d -m u:bob:rwx /usr/container/Databases/

Pour le tester, prenons une sauvegarde avec l'utilisateur bob .

su - bob
tar -cvf container-data.tar /usr/container/Databases/

Et tar apparaîtra et vous pouvez voir que notre utilisateur a pu accéder à tous les fichiers.

Maintenant, à l'intérieur du conteneur, si vous vérifiez avec, getfaclvous remarquerez qu'au lieu de bob, il affiche 3000. C'est parce que l'UID de bob est de 3000 et qu'il n'y a pas un tel utilisateur dans le conteneur, il affiche simplement l'UID qu'il reçoit des métadonnées . Maintenant, si vous créez un utilisateur dans votre conteneur avec useradd -u 3000 bobvous remarquerez que getfaclle nom affiche désormais le bob au lieu de 3000.

Résumé : les autorisations utilisateur que vous attribuez de l'intérieur ou de l'extérieur du conteneur se reflètent donc dans les deux environnements. Ainsi, pour gérer les autorisations des volumes, les UID de la machine hôte doivent être différents des UID du conteneur .