Como definir recursos do Linux em invocações de serviço no modo Docker Swarm

A partir de 20.10, isso está disponível docker service createem --cap-add:

$ docker service create --help
...
      --cap-add list                       Add Linux capabilities
      --cap-drop list                      Drop Linux capabilities

Ou em um arquivo de composição usado com docker stack deploya mesma sintaxe do arquivo da versão 2:

version: "3.9"
services:
  app:
    image: your-image:tag
    cap_add:
    - CAP_NAME1
    - CAP_NAME2
    cap_drop:
    - CAP_NAME3
    - CAP_NAME4

[Resposta original anterior às 20h10]

Atualmente não é suportado, mas o Docker está trabalhando em uma solução. A lógica por trás de não incluir a --cap-addopção cegamente está em um cluster grande, pode haver preocupações de segurança de um gerente que envia contêineres com privilégios adicionais para um trabalhador. O trabalhador pode confiar na execução de contêineres seguros que não podem acessar o host, mas não deseja permitir o acesso root remoto ao host por meio de um contêiner privilegiado.

A discussão sobre isso acabou no github em:

https://github.com/docker/docker/pull/26849#issuecomment-252704844

https://github.com/docker/swarmkit/issues/1030

https://github.com/docker/swarmkit/pull/1722

https://github.com/moby/moby/issues/25885#issuecomment-557790402 e https://github.com/docker/cli/pull/2199

Todas as outras respostas aqui são antigas. O Docker 20.10.0 e mais recente agora oferece suporte à especificação de recursos para serviços Swarm por meio da docker servicelinha de comando e do formato de arquivo Docker Stack YAML .

Na linha de comando, basta especificar --cap-add [capability]ou --cap-drop [capability].

E aqui está um exemplo para adicionar um recurso em um arquivo Docker Stack YAML:

version: "3.9"
services:
  your-service:
    cap_add:
      - CAP_SYS_ADMIN

Encontrei uma solução para resolver o problema e posso usar cap_net_adminno modo enxame.

Você pode modificar o código-fonte do tempo de execução para adicionar os recursos necessários (será uma configuração padrão local).

Por exemplo, adicionei CAP_NET_ADMINao meu tempo de execução (usado nvidia-container-runtime) wanyvic/nvidia-container-runtime .

Depois disso, reconstruí-o, iniciei um contêiner (use o modo swarm), input: capsh --printe CAP_NET_ADMIN podem ser encontrados:

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=

Mas esse método não é bom.

Também não consigo definir cap_addou cap_dropin docker-compose.yml, mas não consigo encontrar uma maneira de resolvê-lo.

Consulte https://hub.docker.com/r/ixdotai/swarm-launcher

Esse repositório é baseado neste comentário/ideia: https://github.com/moby/moby/issues/25885#issuecomment-573355530

Dependendo do caso de uso, uma solução alternativa é vincular a montagem /var/run/docker.sockdo(s) host(s) do enxame ao serviço e, em seguida, executar docker run --privileged ...ou docker run --cap-add ...do serviço para executar seus comandos privilegiados reais. (Você terá que instalar o docker cli na imagem do serviço.) O contêiner mais interno que você executar docker dessa maneira terá os privilégios/recursos do host do enxame em vez do serviço, e o serviço se tornará apenas um fino camada de contêiner.