Acesso ao socket do Docker equivale a root no host: o que montá-lo em um contêiner realmente concede

O que é

A documentação de segurança do Docker afirma que o daemon exige privilégios de root, a menos que o modo Rootless seja usado, e que apenas usuários confiáveis devem poder controlá-lo. O motivo apontado: o Docker permite compartilhar um diretório entre o host e o contêiner sem limitar os direitos de acesso do contêiner. Assim, é possível iniciar um contêiner com o / do host montado e alterar livremente o sistema de arquivos do host.

O socket Unix /var/run/docker.sock é o canal de controle habitual. Quem pode escrever nele controla o daemon.

Por que importa

Várias configurações comuns entregam esse controle sem deixar isso explícito:

• Montar o socket em um contêiner para que ele possa gerenciar outros contêineres (runners de CI, dashboards, proxies reversos que leem labels, sandboxes de agentes que criam contêineres irmãos). O comprometimento desse contêiner se torna o comprometimento do host.
• O grupo docker: ser membro dele equivale, na prática, a ser root na máquina.
• A API TCP sem autenticação de cliente por TLS, que concede o mesmo a qualquer pessoa na rede.

Para agentes, o socket é atraente porque facilita o "execute isso em um contêiner"; mas isso também significa que a sandbox pode escapar de si mesma com uma única chamada de API.

Como aplicar

• Faça o inventário dos contêineres que montam o socket: execute docker inspect em todos os contêineres e procure o caminho do socket nos mounts.
• Quando uma ferramenta só lê metadados de contêineres, coloque na frente do socket um proxy com filtro que permita os endpoints somente leitura de que ela precisa, e monte o proxy no lugar do socket.
• Execute as sandboxes de agentes que precisam iniciar contêineres com o modo Rootless, um daemon separado ou uma fronteira de VM, em vez de usar o daemon do host.
• Mantenha o grupo docker tão pequeno quanto a lista do sudoers e revise os dois em conjunto.
• Nunca exponha a API via TCP sem TLS mútuo; prefira o acesso ao socket por SSH.

Armadilhas

• Bind mount do socket somente leitura (:ro): isso impede a substituição do arquivo do socket, mas não o envio de requisições à API através dele.
• Supor que user namespaces ou um usuário não root dentro do contêiner ajudem; o daemon que executa a requisição continua sendo root.