3

При создании изображения вы можете назначить владельца (chown) и изменить права доступа (chmod) путей в изображении. Однако, когда том монтируется из хоста или другого контейнера, разрешения для этого тома присутствуют, потенциально представляя пользователя / группу, неизвестную контейнеру, внутри которого он монтируется.

Меня интересует предписывающий метод (если таковой существует) для обработки разрешений для пользователей в образе Alpine Docker для томов, смонтированных как на хосте, так и на контейнере.

Два возможных варианта, которые я могу придумать:

  1. Используйте одного и того же пользователя и группу между контейнерами и подключенными томами.
  2. Используйте ACL для управления разрешениями.

Есть ли рекомендуемый подход для решения проблем с разрешениями для подключенных томов, особенно когда uid/gid владельцев не совпадают с пользователями / группами внутри контейнера? Например

В моем образе Alpine Docker мой пользователь www-data имеет значение uid/gid 82 (см. Nginx www-data user id), если я смонтирую том из другого контейнера или хоста, к которому принадлежит пользователь с uid 1001 и gid 1001 объем, как мне справиться с несоответствием в владении и разрешениях?

NB. Некоторые каркасы приложений (например, Symfony) рекомендуют использовать что-то вроде setfacl [ 1 ] для управления разрешениями, но это не представляется возможным в образе Alpine Docker с AUFS, потому что операция "не поддерживается".

Является ли использование ACL анти-паттерном в Docker?

|источник

1 ответ1

2

NB. У StackOverflow возникает следующий вопрос: Каков наилучший способ управления разрешениями для общих томов Docker? который похож на выше и многочисленные ответы, с преобладающим ответом является этим один.

Из экспериментов и чтения многочисленных источников, ищущих предписывающий ответ или общий шаблон, я определил следующее:

При запуске Docker-вне-Docker (DooD) тома данных хоста монтируются с базового хоста. Я помню, как наткнулся на некоторые упоминания об этом в сообщении в блоге, но сейчас я не могу его найти (если / когда я это сделаю, я обновлю этот ответ). Суть в том, что когда вы запускаете Docker через общий docker.sock внутри контейнера, Docker пытается подключить тома с базового хоста. Если вы монтируете том (ы) из другого контейнера, у вас нет этой проблемы.

Назначение разрешений и прав собственности. Проблема, которую я отметил выше (с setfacl не работает), кажется, была проблема пользователя. Я, должно быть, пытался запустить его с разрешениями пользователя без полномочий root или с каталогом, владельцем которого мой пользователь не являлся. Чтобы обойти проблемы с владением, вы можете использовать сценарий docker-entrypoint.sh который будет chown или setfacl в качестве пользователя root перед выполнением команды в качестве пользователя для образа. На данный момент я определил два возможных варианта решения проблем с правами собственности и разрешениями:

  • Используйте sudo чтобы изменить владельца или настроить списки контроля доступа.
  • Позвольте вашему контейнеру работать с использованием пользователя root а затем перейдите к другому пользователю, чтобы выполнить команду, используя gosu или su-exec.

Я решил объединить два вышеизложенных замечания для моего саморецептивного подхода, так что ...

  1. Всякий раз, когда монтируется том хоста в Docker-контейнере, который также разделяет docker.sock с хостом, рекомендуется, чтобы каталоги совпадали. Например, если монтирование тома в Dockerfile объявлено как /var/data тогда монтируйте /var/data с хоста (например, -v /var/data:/var/data). Это особенно важно, если у вас есть файлы или каталоги в /var/data которые вы хотите смонтировать из контейнера в новый контейнер.
  2. Будьте внимательны в отношении разрешений, всегда включайте файл docker-entrypoint.sh который как минимум обновляет владение или контроль доступа для смонтированного каталога.
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .