Chrome sob Docker: CAP_SYS_ADMIN vs privilegiado?

português
#1

Estou executando chromedriver + chrome dentro do Docker em meu ambiente de teste.

Tudo estava funcionando bem até a última atualização do CoreOS.

Estas são as versões que parecem funcionar:

VERSION=1185.5.0VERSION_ID=1185.5.0BUILD_ID=2016-12-07-0937

E esta é uma versão mais recente que faz com que o chrome coredump:

VERSION=1235.4.0VERSION_ID=1235.4.0BUILD_ID=2017-01-04-0450

Olhando para as mudanças, parece que o docker foi atualizado de 1.11.x para 1.12.x, que quebrou setns() ligue para dentro do contêiner. setns() é usado pelo Chrome para criar um namespaces.

Este é o exemplo de saídas:

jsosic-coreos-test-20161207 ~ # docker --versionDocker version 1.11.2, build bac3bae

De dentro de um recipiente nesta caixa:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

Foi assim que a nova versão quebrou:

jsosic-coreos-test-2017-01-04 ~ # docker --versionDocker version 1.12.3, build 34a2ead[root@13ab34c36c82 /]# /opt/google/chrome/chromeFailed to move to new namespace: PID namespaces supported,  Network namespace supported,  but failed: errno = Operation not permittedAborted (core dumped)

O que descobri é que, se eu iniciar o contêiner com qualquer um --cap-add=SYS_ADMIN ou --privileged - Chrome funciona como esperado.

Qual é a diferença entre esses dois switches? Quais recursos são ativados por --privileged?

E, posso permitir setns() dentro do contêiner sem comprometer a segurança?

#2

AFAICS, a documentação sugerir concedendo os recursos necessários para um contêiner, em vez de usar o --privileged alternar. Executando no modo privilegiado parece conceder o recipiente todas as capacidades (exatamente quais são estão listados no primeiro URL, desde que os documentos estejam atualizados).

Em suma, eu diria que --cap-add=SYS_ADMIN concede um subconjunto menor de recursos ao contêiner, em comparação com o --privileged alternar. Evento os exemplos na documentação do Docker (primeiro URL) parecem preferir apenas adicionar o SYS_ADMIN ou NET_ADMIN capacidade quando necessário.

#3

Uma diferença é que -- privileged monta / dev e / sys como RW, onde as sys_admin os monta como RO.Isso significa que um contêiner privilegiado tem acesso total aos dispositivos no sistema. SYS_ADMIN não lhe dá isso.

#4

Obrigado por isto. Eu fiz um problema, usando um monte de suas coisas: Allow setns() in container, or add flag to allow it specifically · Issue #496 · docker/for-linux · GitHub eu acho que deveria ser consertado

#5

Estou quase 2 anos tarde demais, mas há uma solução muito melhor e mais segura no bilhete acima, se você ainda estiver interessado.

#6

Se o pôster original não atualizar a resposta (ele não parece ativo assim), deixe-me saber se você estaria disponível para aceitar um diferente. Perdi horas com isso, só posso imaginar quantas horas salvaremos outras pessoas.