Permisos de usuario dentro y fuera de los contenedores LXC?

Estoy ejecutando algunos servicios dentro de los contenedores Docker LXC en mi servidor y estoy empezando a hacer cosas serias con ellos.

Una cosa que no tengo claro es cómo funcionan los permisos de usuario dentro y fuera del contenedor. Si, por ejemplo, estoy ejecutando MySQL en un contenedor y tengo su directorio de datos configurado /data, que es un volumen Docker, ¿cómo afectan los permisos dentro y fuera del contenedor a las políticas de acceso?

Obviamente, la idea es ejecutar MySQL como su propio usuario en el contenedor (es decir mysql:mysql) y otorgarle derechos de lectura y escritura en ese directorio. Supongo que esto sería bastante sencillo, solo chmodcon el directorio, etc. Pero, ¿cómo funciona esto fuera del contenedor? Ahora que tengo este volumen compartido de Docker llamado 'datos', ¿cómo administro el control de acceso?

Estoy buscando específicamente poder ejecutar un usuario sin privilegios fuera del contenedor Docker que periódicamente accederá al volumen compartido de MySQL y hará una copia de seguridad de los datos.

¿Cómo puedo configurar permisos, usuarios y grupos para que un usuario específico en el host pueda leer / escribir archivos y carpetas en el volumen compartido de Docker?

Desde el lanzamiento de 0,9 acoplable ha bajado LXCy utiliza su propio entorno de ejecución, libcontainer. Su pregunta es un poco antigua, pero supongo que mi respuesta aún aplica la versión que está utilizando.

Respuesta rápida: para comprender los permisos de los volúmenes, puede tomar la analogía de mount --bind Host-Dir Container-Dir. Por lo tanto, para cumplir con sus requisitos, puede usar cualquier método tradicional para administrar los permisos. Supongo que ACL es lo que necesitas .

Respuesta larga: Entonces, como en su ejemplo, tenemos un contenedor llamado dock con un volumen /data.

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

Dentro del contenedor, nuestro servidor MySQL ha sido configurado para usar /datacomo su directorio de datos. Entonces tenemos nuestras bases de datos en el /datainterior del contenedor. Y fuera del contenedor en el sistema operativo host, hemos montado este /datavolumen /usr/container/Databases/y asignamos un bob de usuario normal para realizar copias de seguridad de las bases de datos. Desde la máquina host configuraremos las ACL para el usuario 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/

Para probarlo, hagamos una copia de seguridad con el usuario bob .

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

Y tar aparecerá en la lista y puede ver que nuestro usuario pudo acceder a todos los archivos.

Ahora, desde el interior del contenedor, si verifica con getfacl, notará que en lugar de bob muestra 3000. Esto se debe a que el UID de bob es 3000 y no existe dicho usuario en el contenedor, por lo que simplemente muestra el UID que recibe de los metadatos. . Ahora, si crea un usuario en su contenedor useradd -u 3000 bob, notará que ahora getfaclmuestra el nombre bob en lugar de 3000.

Resumen : por lo tanto, los permisos de usuario que asigna desde dentro o fuera del contenedor se reflejan en ambos entornos. Entonces, para administrar los permisos de los volúmenes, los UID en la máquina host deben ser diferentes de los UID en el contenedor .