Nie można udostępnić woluminu opartego na bezpieczniku do kontenera Docker.

Question

Próbuję udostępnić kontenerowi dokowanego objętość zaszyfrowanego systemu plików do użytku wewnętrznego. Pomysł polega na tym, że kontener będzie zapisywał się do woluminu jak zwykle, ale w rzeczywistości host będzie szyfrował dane przed zapisaniem ich w systemie plików.

Próbuję użyć encfs - to działa dobrze na komputerze, na przykład:

encfs/zaszyfrowany/widocznych

mogę zapisywać pliki do/widoczne, a te dostać szyfrowane . Jednak podczas próby uruchomienia pojemnik z/widzialne jako objętość, np

Döcker metę -i -t --privileged -v/widoczne:/myvolume imageName bash

zrobić uzyskać wolumin w kontenerze, ale znajduje się on w oryginalnym/zaszyfrowanym folderze, nie przechodząc przez system EncFS. Jeśli odmontuję EncFS z/visible, widzę pliki zapisane przez kontener. Nie trzeba dodawać/szyfrować jest puste.

Czy istnieje sposób, aby stacja dokujaca montowała wolumin przez system EncFS, a nie zapisywać bezpośrednio w folderze? W przeciwieństwie do dokowania działa dobrze, gdy używam mount NFS jako wolumin. Piszę do urządzenia sieciowego, a nie do lokalnego folderu, w którym zamontowałem urządzenie.

Dzięki

Answer 1

Nie mogę skopiować Twojego problemu lokalnie. Gdy próbuję narazić plików encfs jako wolumin Docker, otrzymuję błąd podczas próby uruchomienia pojemnik:

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

Więc jest to możliwe, trzeba coś innego się dzieje. W każdym razie to właśnie rozwiązało mój problem:

Domyślnie FUSE pozwala tylko użytkownikowi, który zamontował system plików, na dostęp do tego systemu plików. Podczas korzystania z kontenera Docker ten kontener początkowo działa jako root.

Możesz użyć opcji mocowania allow_root lub allow_other po zamontowaniu systemu plików FUSE. Na przykład:

$ encfs -o allow_root /encrypted /other 

Tutaj allow_root pozwoli użytkownika root mieć Dostęp do montowania, a allow_other pozwoli nikomu mieć dostęp do montowania (pod warunkiem, że uprawnienia UNIX w katalogu umożliwić im dostęp).

Jeśli zamontowany za pomocą allow_root encfs systemem plików, następnie można narazić plików jak objętość dokowanym i zawartość tego plików są prawidłowo widoczna od wewnątrz pojemnika.

Answer 2

Jest to zdecydowanie spowodowane uruchomieniem demona docker, zanim host zamontuje punkt montowania.W tym przypadku i-węzła dla nazwy katalogu jest nadal wskazuje na gospodarzy dysku lokalnym:

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

wtedy, jeśli mocowanie za pomocą demona bezpiecznik jak s3fs:

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

Domyślam się, że doker robi niektóre bootstrap buforowanie nazw katalogów do i-węzłów (ktoś, kto ma większą wiedzę na ten temat, niż może wypełnić to puste miejsce).

Twój komentarz jest poprawny. Jeśli po zakończeniu instalacji ponownie uruchomisz okno dokowane, twój wolumin zostanie poprawnie udostępniony z hosta do twoich kontenerów. (Możesz też po prostu opóźnić uruchamianie dokera do momentu, w którym wszystkie twoje mocowania już się zakończyły)

Co jest interesujące (ale teraz jest kompletne, ponieważ teraz dla mnie) jest to, że po wyjściu z pojemnika i odłożeniu punktu montowania na hoście, wszystkie moi pisze z wewnątrz pojemnika do wspólnej objętości magicznie pojawił (były przechowywane w iwęźle na maszynach gospodarza dysku lokalnym):

[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

może być w stanie obejść ten problem poprzez owinięcie wywołanie mount nsenter aby zamontować go w tej samej przestrzeni nazw co Linux, jak demon docker, np.

nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ... 

Pytanie brzmi, czy to podejście przetrwa demona ponownie się uruchomi. ;-)