Impossibile esporre un volume basato su fusibile a un contenitore Docker

Question

Sto provando a fornire al contenitore docker un volume di file system crittografato per uso interno. L'idea è che il contenitore scriva come al solito nel volume, ma in realtà l'host crittografa i dati prima di scriverli sul filesystem.

Sto cercando di usare EncFS - funziona bene sull'host, ad esempio:

encfs/cifrati/visibili

posso scrivere i file in/visibile, e quelli ottenere criptato . Tuttavia, quando si tenta di eseguire un contenitore con/visibile come il volume, ad esempio:

conduzione finestra mobile -i -t --privileged -v/visibile:/myvolume imagename bash

faccio ottieni un volume nel contenitore, ma si trova nella cartella originale/crittografata, non passando attraverso EncFS. Se disinstalla EncFS da/visible, posso vedere i file scritti dal contenitore. Inutile dire che/criptato è vuoto.

C'è un modo per fare in modo che la finestra mobile monti il ​​volume tramite EncFS e non scriva direttamente nella cartella? Al contrario, la finestra mobile funziona correttamente quando utilizzo un mount NFS come volume. Scrive sul dispositivo di rete e non sulla cartella locale su cui ho montato il dispositivo.

Grazie

Answer 1

non sono in grado di duplicare il problema a livello locale. Se cerco di esporre un filesystem encfs come un volume Docker, ottengo un errore nel tentativo di avviare il contenitore:

FATA[0003] Error response from daemon: Cannot start container <cid>: 
setup mount namespace stat /visible: permission denied 

Quindi è possibile che ci sia qualcosa di diverso da fare. In ogni caso, questo è ciò che ha risolto il mio problema:

Per impostazione predefinita, FUSE consente solo all'utente che ha montato un filesystem di accedere a tale file system. Quando si esegue un contenitore Docker, il contenitore inizialmente funziona come root.

È possibile utilizzare le opzioni di montaggio allow_root o allow_other quando si monta il filesystem FUSE. Per esempio:

$ encfs -o allow_root /encrypted /other 

Qui, allow_root sarà permettere all'utente root per avere accesso al punto di montaggio, mentre allow_other si permetterà a chiunque di avere accesso al punto di montaggio (a condizione che i permessi Unix sulla directory consentono loro l'accesso).

Se ho montato da encfs filesystem utilizzando allow_root, posso quindi esporre tale file system come volume Docker e il contenuto di tale file system sono correttamente visibili dall'interno del contenitore.

Answer 2

Questo è sicuramente perché è stato avviato il daemon docker prima che l'host abbia montato il punto di montaggio.In questo caso l'inode per il nome della directory punta ancora al disco locale eserciti:

ls -i /mounts/ 
1048579 s3-data-mnt 

quindi se si monta utilizzando un demone fusibile come s3fs:

/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt 
ls -i 
1 s3-data-mnt 

La mia ipotesi è che finestra mobile fa un po ' memorizzazione nella cache di bootstrap dei nomi delle directory in inode (qualcuno che ha più conoscenza di ciò che può riempire questo vuoto).

Il tuo commento è corretto. Se si riavvia semplicemente la finestra mobile al termine del montaggio, il volume verrà condiviso correttamente dall'host ai contenitori. (Oppure puoi semplicemente ritardare l'avvio della finestra mobile fino a dopo che tutti i tuoi montaggi hanno finito di montare)

Ciò che è interessante (ma è completo dal momento che per me ora) è che all'uscita dal contenitore e dal disinnesto del punto di montaggio sull'host tutti i miei scrive dall'interno del contenitore al volume condiviso magicamente apparso (venivano conservati al inode sul disco locale macchine host):

[root@host s3-data-mnt]# echo foo > bar 
[root@host s3-data-mnt]# ls /mounts/s3-data-mnt 
total 6 
1 drwxrwxrwx 1 root root 0 Jan 1 1970 . 
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 .. 
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar 
[root@host s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash 
root@5592454f9f4d:/mounts/s3-data# ls -als 
total 8 
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 . 
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 .. 
root@5592454f9f4d:/s3-data# echo baz > beef 
root@5592454f9f4d:/s3-data# ls -als 
total 9 
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 . 
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 .. 
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 beef 
root@5592454f9f4d:/s3-data# exit 
exit 
[root@host s3-data-mnt]# ls /mounts/s3-data-mnt 
total 6 
1 drwxrwxrwx 1 root root 0 Jan 1 1970 . 
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 .. 
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar 
[root@host /]# umount -l s3-data-mnt 
[root@host /]# ls -als 
[root@ip-10-0-3-233 /]# ls -als /s3-stn-jira-data-mnt/ 
total 8 
4 drwxr-xr-x 2 root root 4096 Sep 16 17:28 . 
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 .. 
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar 

Answer 3

potreste essere in grado di ovviare a questo avvolgendo la chiamata monte in nsenter per montarlo nello stesso spazio dei nomi di mount di Linux come il demone docker, ad es.

nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ... 

La domanda è se questo approccio sopravviverà al riavvio di un demone stesso. ;-)