Как установить возможности Linux при вызовах службы режима docker swarm
Я изучаю понятие хранилища, работающего под роем (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 ?
В настоящее время он не поддерживается, но Docker работает над решением. Логика, лежащая в основе невключения опции - cap-add вслепую, находится в большом кластере, могут возникнуть проблемы с безопасностью диспетчера, отправляющего контейнеры с дополнительными привилегиями работнику. Рабочий может доверять запущенным безопасным контейнерам, которые не могут получить доступ к хосту, но не хотят разрешать удаленный корневой доступ к хосту через привилегированный контейнер.
Обсуждение этого вопроса окончено на github по адресу:
https: // github.com/docker/docker/pull/26849#issuecomment-252704844
Я нашел решение проблемы и могу использовать 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с узла(ов) swarm к службе, затем запуститеdocker run --privated ...илиdocker run --cap-add ...из службы для выполнения ваших реальных привилегированных команд. (Вам нужно будет установить docker cli в образе для службы.) Самый внутренний контейнер, который вы запускаете в докере таким образом, будет иметь привилегии/возможности хоста swarm, а не службы, и служба просто станет тонкой. контейнерный слой.
Все остальные ответы здесь устарели. Docker 20.10.0 и новеетеперь поддерживает указание возможностей для служб Swarm с помощьюdocker serviceкомандной строкии формата файла YAML Docker Stack.
В командной строке вы просто указываете --cap-add [возможность]или --cap-drop [возможность].
А вот пример добавления возможности в файл YAML стека Docker:
version: "3.9"
services:
your-service:
cap_add:
- CAP_SYS_ADMIN