Как правильно работать с пользователями в Docker-контейнерах?

Question

[Vigilo Confido]

Пытался вникнуть самостоятельно, но не хватает то ли усердности, то ли опыта с докер-контейнерами.

Как работает параметр user при запуске докер-контейнеров и, самое главное - как обрабатывать его при написании своих Dockerfile'ов?

На данный момент видел готовые контейнеры с обработкой параметра (например, mariadb) - но при этом часто при первом запуске он перетаскивает права в настроенном волюме на uid=999 (system-coredump) - от чего впечатление, что user не работает как некий "прокси для прав", заставляя все "внешние взаимодействия" осуществлять из под указанного user'а.

В самосборных контейнерах (например, проектах с использованием php-fpm и внешними волюмами) пока что передают в env-переменные значения UID=xxxx и GID=xxxx, которые обрабатываются entrypoint'ом, создавая юзера внутри контейнера с нужными ID и запуская fpm от него.

Answer 1

[Георг Гаал]

> Как работает параметр user при запуске докер-контейнеров и, самое главное - как обрабатывать его при написании своих Dockerfile'ов?

никак. Параметр user это костыль, который позволяет софт запускать не от root'ового пользователя. Объяснять почему запускать в докере под пользователем 0 (root) что-либо - долго, но если кратко, то это очень плохо и не секурно. Соответственно, правильный путь Вы уже поняли:

1. определять entrypoint контейнера как свой самописанный docker-entrypoint.sh скрипт
   
2. в docker run оставить возможность передать ключ (точнее - переменную среды) USER
   
3. в docker-entrypoint.sh его (ее, переменную среды) подхватывать и изменять через chmod/chown нужные файлы в bind-mount (каталогах, доступных и в контейнере, и на хосте) и через утилиту gosu переключаться в нужного пользователя
   
4. и только как завершающий этап - запускать свой сервис в докере
   

Что еще добавить. Все эти проблемы с chown/chmod возникают только если необходимо перегонять файлы между контейнером и хостом. Если этой задачи не стоит, то и все приседания и не нужны. А если все-таки нужно, то есть еще два способа это сделать без колдования с правами:

• команда docker cp
  
• использование pipe: docker exec container_name cat MY_FILE > path_on_host или аналогично
  

Comments

[Vigilo Confido]

Да, про несекьюрность root'а уже в курсе.

Не до конца понял следующий момент:

в docker run оставить возможность передать ключ USER
в docker-entrypoint.sh его подхватывать

то есть передаваемый ключ USER все таки обрабатывается не какой-то логикой внутри ядра докера, а всего лишь прокидывается как параметр? как правильно получить переданное значение вида "1001:1001" в entrypoint?

[Vigilo Confido]

UPD. Перепрочел часть ту часть, что "точнее - переменную среды" - то есть использование конкретно логики с параметром user - дурной тон и рулить лучше через передачу env, если на этот раз правильно понял.

Если Вы еще сможете обьяснить как все таки по стандарту действует (или должен действовать в вакууме) параметр user, который родной, докеровский - я был бы благодарен.

[Георг Гаал]

ключ --user и равно --group - обрабатываются логикой docker'а, но если не сделать каких-либо дополнительных действий (например, у Вас уже есть файлы в образе), то все равно Ваш сервис работать не будет.

как правильно получить переданное значение вида "1001:1001" в entrypoint?
docker run -e USER=1001 -e GROUP=1001 blablabla

в docker-entrypoint.sh сначала поправляете права на все файлы через chown/chmod, а затем через gosu переключаетесь в нужного пользователя (заданного через USER/GROUP).
Пример - www.inanzzz.com/index.php/post/dna6/unning-docker-...

Если же еще дополнительно передать параметр --user, то все сломается, т.к. скорее всего не хватит прав на изменение прав файлов. Поэтому рассматривайте ключи --user & --group именно как дополнительную опцию (иногда оно пригождается, когда нужно внутри контейнера зайти в рута), которой скорее пользоваться не следует.

А вообще идеальный вариант - писать переносимый код, чтобы не нужно было всех этих приседаний с chmod/chown etc.

[Георг Гаал]

Если Вы еще сможете обьяснить как все таки по стандарту действует (или должен действовать в вакууме) параметр user, который родной, докеровский - я был бы благодарен.

Если совсем кратко. Вот стартует контейнер. В нем порождается процесс с PID=0. Если стоит --user=0 или параметр не указан, то этот процесс стартует с правами рута. Если же параметр есть, то этот процесс стартует с UID того пользователя, который указан. Беда в том, что потом уже после запуска привилегии будет не поднять. В общем-то это и соответствует идеологии контейнеров и принципов наименьших необходимых прав.

Дополнительно - внутри контейнера через docker exec можно запустить любую программу.

gaal@linux-x1:~> docker exec --help

Usage: docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

Run a command in a running container
...
-u, --user string Username or UID (format:
[:])

Answer 2

[planc]

user - это словесное представление для удобства, как домены в интернете
у файла нет параметра имя юзера, имя группы юзера, там как ip адреса - номер юзера и номер группы юзера

допустим я юзер dka на хосте uid/gid 1000

у меня папка /tmp/docker с кодом

я запускаю дебиан в контейнере и добавляю туда свою папку, которая будет /code

docker run -v /tmp/docker:/code -it --rm debian bash

создаю юзера внутри контейнера с uid 1000 gid 1000 ( как у моего юзера на хосте)

root@364785fa76ce:/code# groupadd -g 1000 my_docker_user_group
root@364785fa76ce:/code# useradd --uid 1000 --gid 1000 my_docker_user

прыгаю под нового юзера с помощью su (в докер файле это директива USER)

root@364785fa76ce:/code# su my_docker_user

все, теперь я могу кодить на хосте, а запускать в контейнере и у меня не будет проблем с правами на файлы

Comments

[VadzimZ]

docker run -it --rm -v $(pwd):/app --cgroupns host debian:latest bash
Вам нужен параметр --cgroupns host и всё

Answer 3

[VadzimZ]

Зачем городить внутри контейнера эти конструкции с useradd --uid 1000 --gid 1000 если можно запустить контейнеры с параметром --cgroupns host который как раз и пробросит нужный uid и guid в контейнер.
И ваши файлы на хосте не будут менять uid на рутовый.

$  docker run -it --rm -v $(pwd):/app --cgroupns host debian:latest bash
Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
bd8f6a7501cc: Pull complete 
Digest: sha256:ba4a437377a0c450ac9bb634c3754a17b1f814ce6fa3157c0dc9eef431b29d1f
Status: Downloaded newer image for debian:latest
root@aa219fb22248:/# cd app/
root@aa219fb22248:/app# ls -la
total 28
drwxrwxr-x 3 1000 1000 4096 Apr 30 11:58 .
drwxr-xr-x 1 root root 4096 Apr 30 13:59 ..
drwxrwxr-x 8 1000 1000 4096 Apr 30 11:59 .git
-rw-rw-r-- 1 1000 1000 1674 Apr 29 20:45 Dockerfile
-rw-rw-r-- 1 1000 1000  491 Apr 30 11:58 README.md