Como impedir que o Daemon do Docker monte o sistema de arquivos raiz do host no contêiner

Question

Eu tenho a seguinte configuração de contêineres.

Em um servidor bare metal, há dois Daemons Docker instalados e em execução.

1. Principal Docker Daemon Executa os contêineres de aplicativos expondo 80/443 ao mundo externo.
2. Daemon do Docker de Plugin Executa alguns contêineres fornecidos pelo cliente que se comunicam com meu aplicativo por meio do 80/443.

Gostaria de fornecer ao cliente acesso à API (2376) do Daemon do encaixe de plug-in para que o cliente possa implantar / iniciar / parar seus próprios contêineres. O cliente só terá acesso à API e não ao host (SSH).

O problema que enfrento atualmente é: e se os clientes executarem um contêiner que faz algo estúpido como docker run -v /:/host/root ubuntu rm -rf /host/root .

A minha pergunta é o que posso fazer para evitar que o Daemon do Plugin Docker monte a raiz / ou qualquer outro diretório fora de /home/user/ ,

• É uma opção para iniciar o Daemon do Docker em /home/user/ ?
• Posso usar alguma mágica LSM (Linux Security Modules SELinux / Apparmor) para impedir que o daemon do docker monte alguns ou todos os caminhos de host, exceto home de usuários ou var / docker / libs?
• A --userns-remap pode ajudar-me a alcançar o meu objetivo?
• Existem outras opções disponíveis, exceto VMs?

O servidor pertence inteiramente a um único cliente. Portanto, segurança ou vazamento de dados não é minha principal preocupação. O que eu realmente quero evitar é que alguém no Daemon de plug-in esteja fazendo algo estúpido, que influencia meus contêineres que são executados no Principal Docker Daemon . Eu gostaria de manter a mente enxuta e manter o fluxo de trabalho do docker e não criar um fluxo de trabalho extra para a criação de VMs.

    

Answer 1

O SELinux impedirá que qualquer coisa que não esteja rotulada corretamente seja montada como um volume dentro de um contêiner docker, como prova, aqui usando um único arquivo, a mesma política se aplica aos diretórios:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      30

Usando o arquivo de amostra:

$ cat sample_script.sh 
echo 'Hello, world'

Seu contexto de segurança padrão é:

$ ls -lrtZ sample_script.sh 
-rw-------. 1 david david unconfined_u:object_r:user_home_t:s0 20 Oct  3 17:18 sample_script.sh

Tentar usar esse arquivo em um contêiner falha conforme o esperado:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.sh
bash: sample_script.sh: Permission denied

E uma negação de AVC será registrada:

$ sudo ausearch -m avc -ts recent
time->Mon Oct  3 17:39:28 2016
type=AVC msg=audit(1475512768.444:784): avc:  denied  { read } for  pid=28720 comm="bash" name="sample_script.sh" dev="dm-13" ino=101062112 scontext=system_u:system_r:svirt_lxc_net_t:s0:c457,c992 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

Depois de alterar o contexto de segurança para um Docker, é possível usar:

$ sudo chcon -Rt svirt_sandbox_file_t sample_script.sh
$ ls -lrtZ sample_script.sh 
-rw-------. 1 david david unconfined_u:object_r:svirt_sandbox_file_t:s0 20 Oct  3 17:18 sample_script.sh 

O contêiner agora tem acesso ao arquivo:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.sh
Hello, world

Mais informações sobre o Docker e o SELinux no documentação oficial da Red Hat e este artigo por Dan Walsh.

    

Answer 2

Ok, então você parou este exemplo. Mas parece que este exemplo ainda funciona: link

E desde que você tenha um xeque-mate de casca de ovo.