Quero usar um servidor para hospedar vários contêineres docker. Quero dar a outro usuário a possibilidade de gerenciar novos contêineres docker, mas não quero dar a ele acesso a todos os outros contêineres que iniciei, pois eles podem conter dados confidenciais.
Existe uma maneira de criar uma configuração segura que não exija a criação de uma máquina virtual?
Responder1
Pergunta original: Como permitir que o usuário gire seus próprios contêineres e não acesse os outros contêineres?
(Esta foi a minha resposta originalmente, mas talvez eu tenha entendido mal a pergunta ou a pergunta não tenha sido tão clara, mantive a solução original aqui de qualquer maneira)
O Docker não fornece esse recurso por si só, mas existem várias maneiras de fazer isso.
A idéia é que os comandos do docker exijam que o usuário esteja no sudo ou no grupo docker para ser executado, portanto, se você deseja apenas que o usuário gire um novo contêiner, em vez de adicionar o usuário ao grupo sudo ou docker, que fornece acesso total a todos os docker comandos, você pode colocar na lista de permissões apenas vários comandos do docker para esse usuário.
Por exemplo, se você quiser permitir que o usuário tom execute o seguinte contêiner:
sudo docker container run --it --name ubuntu-tom ubuntu:latest bash
Você pode adicionar a seguinte linha ao seu arquivo sudoers executandosudo visudo:
tom ALL=NOPASSWD: /usr/bin/docker container run --it --name ubuntu-tom ubuntu:latest bash
Isso permite que o usuário tom execute este comando docker específico como root sem exigir uma senha. Quaisquer outros comandos do docker permanecem indisponíveis para o usuário tom.
Outra alternativa é configurar o shell restrito, mas não entrarei em detalhes aqui.
Pergunta atualizada: Como limitar o usuário para gerenciar novos containers?
Não tenho conhecimento de uma possível solução usando apenas o Docker.
Parece que você precisa de um orquestrador como Kubernetes ou ECS.
Dessa forma, o orquestrador possui o daemon docker e você pode utilizar a camada de permissão fornecida pelo orquestrador. Esseartigofornece um ótimo exemplo de restrição do acesso do usuário a um namespace.
Responder2
Deve ser bastante simples de executar dockerdpor usuário e utilizar permissões de arquivo para separar o acesso do usuário.
Acabei de encontrar um tutorial usando modelos do systemd para obter esta configuração: https://www.jujens.eu/posts/en/2018/Feb/25/multiple-docker/
Responder3
Por que você não implementa o portainer? Ele tem muitos recursos como controle de usuário, menu gui e muito mais, você não precisa criar usuário no servidor também
Responder4
A API docker não tem esse recurso internamente, trate o acesso direto a ele como um recurso de nível sysadmin porque dá aos usuários acesso root ao servidor. Portanto, para implementar isso, você precisará fornecer seu próprio acesso indireto à API ou usar outra ferramenta que forneça essa funcionalidade além do docker.
Você pode fornecer um script que seja acessado pelo sudo e que execute todas as verificações de segurança nos comandos antes de executá-los. A maneira mais fácil de implementar isso seria adicionar um rótulo em cada objeto criado (contêiner, volume, rede, etc.) e, em seguida, retornar apenas os objetos que correspondam a esse filtro em quaisquer consultas e limitar os comandos executados apenas para objetos com esses rótulos. Não é trivial escrever, então só vi pessoas optarem por opções posteriores. No entanto, se os comandos e contêineres executados forem muito limitados, esta pode ser uma solução boa o suficiente para você.
O namespace do Kubernetes fornece essa funcionalidade e é executado no docker. Isso é muito para implementar, então a maioria das pessoas só segue essa direção se precisarem de muito mais funcionalidades que o Kubernetes oferece.
Existem várias ferramentas de terceiros, algumas comerciais, que controlam o acesso do usuário. Portainer e Rancher são dois populares, mas não tenho experiência pessoal com eles.
Docker fornece uma oferta empresarial com isso incluído, chamada UCP. Você pode fornecer aos usuários acesso docker api/cli que passa pelo UCP para verificação de RBAC antes que a solicitação seja enviada ao mecanismo docker subjacente.