Read this article in English.
Gerenciar o Docker remotamente pode facilitar bastante a operação, mas expor sua API sem as medidas de segurança adequadas cria riscos sérios. Neste guia, mostro duas formas de habilitar o acesso remoto ao Docker Engine: uma rápida, porém insegura, e outra protegida por TLS.
1. Configuração rápida e insegura (não recomendada para produção)
Este método expõe a API do Docker via TCP sem criptografia ou autenticação. Isso deixa o ambiente vulnerável e só deve ser utilizado em testes controlados.
1.1 Como habilitar o acesso remoto sem TLS
- Edite o arquivo de configuração do Docker:
sudo vim /etc/docker/daemon.json- Adicione as linhas abaixo:
{
"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"]
}- Ajuste o arquivo de serviço do Docker:
sudo sed -i 's# -H fd://# #g' /lib/systemd/system/docker.service
sudo systemctl daemon-reload
sudo systemctl restart docker.service
Confirme se a porta está aberta:
sudo lsof -i:2376
Teste o acesso remoto:
sudo docker -H <SERVER_IP>:2376 --version2. Configuração segura com TLS (recomendada para produção)
Em ambientes de produção, o TLS é indispensável. Ele garante que apenas clientes autenticados interajam com a API do Docker e protege tanto os dados quanto a infraestrutura.
2.1 Gerando os certificados TLS
- Crie uma autoridade certificadora (CA):
openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
- Gere e assine o certificado do servidor:
openssl genrsa -out server-key.pem 4096
openssl req -subj "/CN=<SERVER_DNS>" -sha256 -new -key server-key.pem -out server.csr
echo subjectAltName = DNS:<SERVER_DNS>,IP:<SERVER_IP> >> extfile.cnf
echo extendedKeyUsage = serverAuth >> extfile.cnf
openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf- Gere e assine o certificado do cliente:
openssl genrsa -out key.pem 4096
openssl req -subj "/CN=client" -sha256 -new -key key.pem -out client.csr
echo extendedKeyUsage = clientAuth > extfile-client.cnf
openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf
- Empacote os certificados:
No servidor:
mkdir certs
cp ca.pem server-cert.pem server-key.pem certs/
tar -zcvf server-key.tar.gz certs
No cliente:
tar -zcvf client-key.tar.gz ca.pem cert.pem key.pem
2.2 Configurando o Docker para utilizar TLS
- Instale os certificados no servidor:
sudo tar -zxvf server-key.tar.gz -C /etc/docker/- Edite o arquivo de configuração do Docker:
sudo vim /etc/docker/daemon.json
Adicione:
{
"hosts": ["unix:///var/run/docker.sock", "tcp://<SERVER_IP>:2376"],
"tls": true,
"tlscacert": "/etc/docker/certs/ca.pem",
"tlscert": "/etc/docker/certs/server-cert.pem",
"tlskey": "/etc/docker/certs/server-key.pem",
"tlsverify": true
}- Reinicie o Docker:
sudo systemctl daemon-reload
sudo systemctl restart docker.service
2.3 Testando o acesso remoto seguro
Extraia os certificados do cliente
mkdir client-keys
tar -zxvf client-key.tar.gz -C client-keys
Conecte-se ao Docker de forma segura:
sudo docker --tlsverify --tlscacert=client-keys/ca.pem --tlscert=client-keys/cert.pem --tlskey=client-keys/key.pem -H=<SERVER_DNS>:2376 run -ti nginx
Considerações finais: proteja a API do Docker
Habilitar o acesso remoto ao Docker sem proteção representa um risco considerável. A configuração rápida pode ser útil em testes isolados, mas não deve ser utilizada em produção. Nesses ambientes, proteja a API com TLS para impedir acessos não autorizados.
🔹 Pontos principais:
- 🚀 O gerenciamento remoto do Docker amplia as possibilidades de automação.
- ⚠️ Expor o Docker sem TLS deixa o ambiente vulnerável.
- 🔒 O TLS permite que apenas clientes autorizados se conectem.
💡 Quer saber mais? Consulte o guia oficial de segurança do Docker.
💡 Quem sou eu?
Sou Gabriel Carmo, CNCF Kubestronaut, com certificações CKA, CKAD, CKS, KCNA e KCSA, além de Red Hat Certified OpenShift Administrator.
Atuo em DevOps Engineering, construindo e evoluindo plataformas Kubernetes multi-cloud. Meu trabalho tem como foco reduzir a carga cognitiva das equipes de engenharia por meio de platform engineering, automação, GitOps e experiências self-service.
No dia a dia, conecto infraestrutura como código, cloud networking, governança, segurança, observabilidade e práticas de SRE para criar plataformas mais padronizadas, resilientes e fáceis de operar.