Chrome em Docker: CAP_SYS_ADMIN vs privileged?

8

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

Tudo estava funcionando bem até o mais recente upgrade do CoreOS.

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

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

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

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

Olhando as alterações, parece que a janela de encaixe foi atualizada de 1.11.x para 1.12.x, que quebrou setns() de chamada dentro do contêiner. setns() é usado pelo Chrome para criar namespaces.

Estas são as saídas de exemplo:

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

De dentro de um contêiner nessa 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 --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

O que descobri é que, se eu iniciar o contêiner com --cap-add=SYS_ADMIN ou --privileged , o Chrome funcionará 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?

    
por Jakov Sosic 07.01.2017 / 14:13

1 resposta

6

AFAICS, a documentação sugere que concede os recursos necessários para um contêiner, em vez de usar a opção --privileged . Execução no modo privilegiado parece conceder o contêiner todos os recursos (exatamente quais deles estão listados no primeiro URL, desde que os documentos estejam atualizados).

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

    
por 08.01.2017 / 12:29