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


26

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?


2
Avec les utilisateurs (mais pas de dockersupport pour le moment), le conteneur LXC peut être exécuté en tant qu'utilisateur non privilégié. Sinon, l' rootutilisateur à l'intérieur du conteneur pourrait potentiellement éclater si le conteneur est mal configuré. C'est-à-dire que l' roothôte est rootdans un conteneur dans un conteneur LXC privilégié.
0xC0000022L

1
rootpeut, en passant, également exécuter des conteneurs non privilégiés . Il est important de définir un mappage pour les utilisateurs .
0xC0000022L

Réponses:


21

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 .


Docker pour Ubuntu a au moins un nom de package de lxc-docker, cela signifie-t-il qu'il n'utilise pas LXC? Est-ce que ce qui précède s'applique toujours dans ce cas?
Naftuli Kay

@NaftuliTzviKay oh, désolé. Ensuite, il faut utiliser LXC (je suppose que cela apt-get infopeut avoir les détails) car dans ubuntu il y a un autre paquet docker.ioque j'ai utilisé. Je ne suis pas allé longtemps avec Ubuntu, car Docker et RedHat se sont maintenant associés. Il est donc préférable d'utiliser RHEL ou CentOS comme système d'exploitation de base, sinon vous pouvez simplement utiliser LXC.
débutant

Même dans lxc-dockercela semble fonctionner comme prévu. J'ai créé un utilisateur avec un UID de 3000, j'ai touché un fichier dans un volume partagé et j'ai pu voir depuis le système d'exploitation hôte que le fichier existait et appartenait à un utilisateur avec l'ID 3000.
Naftuli Kay
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.