Uprawnienia użytkownika wewnątrz i na zewnątrz kontenerów LXC?

Korzystam z niektórych usług w kontenerach Docker LXC na moim serwerze i zaczynam robić z nimi poważne rzeczy.

Nie jestem pewien, w jaki sposób działają uprawnienia użytkownika wewnątrz i na zewnątrz kontenera. Jeśli na przykład uruchamiam MySQL w kontenerze, a jego katalog danych jest ustawiony na /datawolumin Docker, w jaki sposób uprawnienia wewnątrz i na zewnątrz kontenera wpływają na zasady dostępu?

Oczywiście pomysł polega na uruchomieniu MySQL jako własnego użytkownika w kontenerze (tj. mysql:mysql) I nadaniu mu prawa do odczytu i zapisu w tym katalogu. Zakładam, że byłoby to dość proste, po prostu chmodkatalogowanie itp. Ale jak to działa poza kontenerem? Teraz, gdy mam ten udostępniony wolumin Docker o nazwie „dane”, jak zarządzać kontrolą dostępu do niego?

W szczególności szukam możliwości uruchomienia nieuprzywilejowanego użytkownika poza kontenerem Docker, który będzie okresowo uzyskiwał dostęp do udostępnionego woluminu MySQL i tworzył kopie zapasowe danych.

Jak skonfigurować uprawnienia, użytkowników i grupy, aby określony użytkownik na hoście mógł czytać / zapisywać pliki i foldery w woluminie udostępnionym Docker?

Od czasu wydania 0,9 Docker spadło LXCi wykorzystuje swoje własne środowisko wykonawcze, libcontainer. Twoje pytanie jest trochę stare, ale wydaje mi się, że moja odpowiedź nadal dotyczy używanej wersji.

Szybka odpowiedź: Aby zrozumieć uprawnienia dotyczące woluminów, możesz zastosować analogię do mount --bind Host-Dir Container-Dir. Aby spełnić Twoje wymagania, możesz użyć tradycyjnych metod zarządzania uprawnieniami. Myślę, że ACL jest tym, czego potrzebujesz .

Długa odpowiedź: tak jak w twoim przykładzie mamy kontener o nazwie dock z woluminem /data.

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

Wewnątrz kontenera nasz serwer MySQL został skonfigurowany do używania /datajako katalogu danych. Mamy więc nasze bazy danych w /datapojemniku. Poza kontenerem w systemie operacyjnym hosta podłączyliśmy ten /datawolumin /usr/container/Databases/i przypisujemy zwykłego użytkownika bobowi do wykonywania kopii zapasowych baz danych. Z komputera hosta skonfigurujemy listy ACL dla użytkownika 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/

Aby to przetestować, wykonaj kopię zapasową za pomocą boba użytkownika .

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

A tar wyświetli listę i zobaczysz, że nasz użytkownik mógł uzyskać dostęp do wszystkich plików.

Teraz z wnętrza kontenera, jeśli skontaktujesz się z nim getfacl, zauważysz, że zamiast bob pokazuje 3000. Jest tak, ponieważ UID bob to 3000 i nie ma takiego użytkownika w kontenerze, więc po prostu wyświetla UID otrzymany z metadanych . Teraz, jeśli utworzysz użytkownika w swoim kontenerze useradd -u 3000 bob, zauważysz, że teraz getfaclpokazuje nazwę bob zamiast 3000.

Podsumowanie : więc uprawnienia użytkownika przypisywane z wnętrza lub z zewnątrz kontenera odzwierciedlają oba środowiska. Aby więc zarządzać uprawnieniami do woluminów, identyfikatory UID na hoście muszą być inne niż identyfikatory UID w kontenerze .