Как настроить возможности Linux для вызовов службы в режиме Docker Swarm Mode
Я изучаю понятие хранилища под роем (1.12.x).
Один контейнер будет начинаться с:docker run -d --cap-add IPC_LOCK -p 8200:8200 -p 8215:8125 --name vault --volume /vagrant/vault:/vagrant/vault vault server -config=/path/to/vault.hcl
но когда я хочу запустить это в Swarm в качестве службы, кажется, нет никакого способа указать IPC_LOCK
возможность, чтобы заблокировать зашифрованный обмен для службы хранилища в этом случае.
Как установить флаги --cap-add при запуске службы в режиме роя с docker service create
команда?
4 ответа
В настоящее время он не поддерживается, но Docker работает над решением. Логика не включая --cap-add
Вариант вслепую находится в большом кластере, могут возникнуть проблемы с безопасностью менеджера, отправляющего контейнеры с дополнительными привилегиями работнику. Работник может доверять запуску защищенных контейнеров, которые не могут получить доступ к хосту, но не хотят разрешать удаленный корневой доступ к хосту через привилегированный контейнер.
Обсуждение этого на github закончено на:
https://github.com/docker/docker/pull/26849
Все остальные ответы здесь старые. Docker 20.10.0 и новее теперь поддерживает указание возможностей для сервисов Swarm черезdocker service
командной строки и формата файла YAML Docker Stack .
В командной строке вы просто указываете--cap-add [capability]
или--cap-drop [capability]
.
Вот пример добавления возможности в YAML-файл Docker Stack:
version: "3.9"
services:
your-service:
cap_add:
- CAP_SYS_ADMIN
Я нашел решение, чтобы решить проблему, и я могу использовать cap_net_admin
в режиме роя.
Вы можете изменить исходный код среды выполнения, чтобы добавить необходимые вам возможности (это будет локальная настройка по умолчанию).
Например, я добавил CAP_NET_ADMIN
в мое время выполнения (используется nvidia-container-runtime
) wanyvic / nvidia-container-runtime.
После этого я перестроил его, запустил контейнер (в режиме роя), введите: capsh --print
и CAP_NET_ADMIN можно найти:
root@25303a54ebb3:/# capsh --print
Current:=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=
Но этот метод не хорош.
Я тоже не могу установить cap_add
или же cap_drop
в docker-compose.yml
, но я не могу найти способ решить это.
См. https://hub.docker.com/r/ixdotai/swarm-launcher.
Это репо основано на этом комментарии / идее: https://github.com/moby/moby/issues/25885#issuecomment-573355530
В зависимости от варианта использования обходной путь - привязать-монтировать
/var/run/docker.sock
от хоста (ов) роя к службе, затем запуститеdocker run --privileged ...
или жеdocker run --cap-add ...
из службы для выполнения ваших реальных привилегированных команд. (Вам нужно будет установить docker cli в образ для службы.) Самый внутренний контейнер, который вы запускаете таким образом, будет иметь привилегии / возможности хоста роя, а не службы, и служба просто станет тонкой контейнерный слой.