Каков предписывающий способ управления разрешениями для подключенных томов в основанном на Alpine Docker?

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

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

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

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

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

В моем образе Альпийского Докера мой www-data У пользователя uid/gid 82 (см.: nginx www-data user id), если я смонтирую том из другого контейнера или хоста, на котором пользователь с uid 1001 и гид 1001 владеет томом, как мне справиться с несоответствием в правах собственности и разрешениях?

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

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

Источник

1 ответ

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

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

При запуске тома данных хоста Docker-outside-of-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 файл, который, по крайней мере, обновляет владельца или контроль доступа для смонтированного каталога.
Источник
Другие вопросы по тегам