Como proteger um host do docker para não permitir o enraizamento

Question

Estou tentando tornar o Docker em um servidor mais seguro. O principal problema é que a maioria das pessoas diz "se uma pessoa tem acesso ao docker, eles podem ser root também" para um ponto de administração de poucos, isso não é algo que você gostaria.

Para elaborar, eles podem usar -v e montar /etc em /mnt no contêiner e alterar o arquivo de sombra e obter acesso ao host. Eles podem usar -d ou opção privilegiada para fazer mais também.

Então, basicamente, há algumas coisas que eu quero "experimentar" e restringir.

1. Montagens de vinculação de volume
2. Privilegiada
3. --add-cap
4. -d (certos itens?)

Minhas ideias até agora:

• Alias para um script bash para o docker, use o sudo nele e regexe tudo o que eles não devem fazer.
• Ligue a API remota, proteja-a e talvez inverta o proxy com nginx e regex em nginx as coisas que eles não devem fazer.
• Use outras ferramentas? Mesos / Maratona / Enxame / Estaleiro / Qualquer que seja

Os itens opcionais seriam fazer com que os contêineres se comprometam com o código git e permitir que um "verificador" verifique o conteúdo do Dockerfile e crie a imagem para eles. Em seguida, assine essa imagem e implemente-a automaticamente. (mas isso não lhes daria muita liberdade)

Além disso, remover o volume de ligação não é o mais bonito. Seria muito mais simples se tivéssemos um plug-in para o docker que diz "você só pode montar em /data , como usuário X", em que USER no Dockerfile é esse usuário X.

Algo como docker-novolume-plugin já é um bom começo para os volumes, não restringe o vínculo volumes embora.

No final, a pergunta seria: como posso deixar os usuários criar / extrair / executar imagens do docker como seu próprio usuário / docker e não conseguir enraizar o sistema. Não precisa ser perfeito, desde que funcione.

    

Answer 1

Proteger um mecanismo docker requer prestar atenção a muitos aspectos diferentes e a defesa em profundidade é sempre sobre camadas de segurança.

Um dos requisitos listados, restringindo o que os usuários podem comandar o mecanismo docker , provavelmente é um dos mais importantes, pois, a partir de agora, o mecanismo docker não implementa um controle de autorização.

Suas alternativas incluem:

• soluções de código fechado, como o Twistlock , um projeto que implementa o RBAC e o controle de diretivas para acessar a docker API

• OpenShift Origin , um projeto de código aberto que implementa controle de acesso baseado em função na forma de restrições de segurança e políticas de autorização refinadas . É bastante fácil de implantar e ajudaria muito a ter uma solução pronta para uso.

Também sugeriria examinar os diferentes sistemas operacionais nos quais um docker engine pode ser implementado, e aconselharia a não usar um sistema operacional de finalidade geral, mas um sistema especializado, como Atomic . Ambos, Atomic e OpenShift juntos, garantirão que você também possa:

• Digitalize suas imagens regularmente.
• Use um registro confiável
• Defina perfis seccomp para seus contêineres. Melhorias nessa tecnologia e sua implementação é um trabalho em andamento no mundo docker como um todo.
• Solte os recursos que não são necessários para o aplicativo no contêiner.
• Use SELinux . Muitas das outras medidas de segurança listadas possuem limitações, mas o SELinux funciona muito bem no fornecimento de uma rede segura quando tudo o mais falha. Alguns exemplos: ele ajudará a limitar o acesso ao docker socket , controlará se Compartilhamento de descritores de arquivos entre contêineres é permitido, ele pode atribuir diferentes níveis de MCS para cada contêiner / grupo de contêineres para isolá-los do host e de outros contêineres.