Implantação Segura com Docker Compose + Ubuntu
Em startups do Vale do Silício, o Docker Compose é uma das ferramentas preferidas para implantar e gerenciar rapidamente aplicações containerizadas. Contudo, a conveniência costuma vir acompanhada de riscos de segurança. Como engenheiro de confiabilidade de sites (SRE), estou ciente de que vulnerabilidades podem gerar consequências catastróficas. Este artigo compartilha as melhores práticas de segurança que compilei no meu trabalho real combinando Docker Compose com sistemas Ubuntu, ajudando você a aproveitar a conveniência do Docker Compose enquanto garante a segurança do sistema.
I. Reforço da Segurança do Sistema Ubuntu
Antes de implantar contêineres, é crucial garantir a segurança do host Ubuntu. Aqui estão alguns passos essenciais:
1. Atualizar Ubuntu e Docker Regularmente
Mantenha tanto o sistema quanto o Docker atualizados para corrigir vulnerabilidades conhecidas:
sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin
2. Restringir Permissões de Gerenciamento do Docker
Controle estritamente as permissões de gerenciamento do Docker para impedir ataques de elevação de privilégios:
sudo usermod -aG docker deployuser
# Impedir que usuários regulares obtenham facilmente permissões de gerenciamento do Docker
3. Configurar o Firewall do Ubuntu (UFW)
Restrinja o acesso de rede de forma razoável para evitar acessos não autorizados:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
4. Configurar Adequadamente a Interação entre Docker e UFW
Por padrão, o Docker ignora o UFW ao configurar iptables, portanto, recomenda‑se controle manual:
Modifique o arquivo de configuração do Docker:
sudo nano /etc/docker/daemon.json
Adicione o seguinte conteúdo:
{
"iptables": false,
"ip-forward": true,
"userland-proxy": false
}
Reinicie o serviço Docker:
sudo systemctl restart docker
Vincule explicitamente endereços no Docker Compose:
services:
webapp:
ports:
- "127.0.0.1:8080:8080"
II. Melhores Práticas de Segurança no Docker Compose
As configurações a seguir se aplicam ao Docker Compose v2.4 ou superior. Observe as diferenças entre os modos não‑Swarm e Swarm.
1. Restringir Permissões dos Contêineres
Contêineres que rodam como root por padrão apresentam alto risco; altere para usuários não‑root:
services:
app:
image: your-app:v1.2.3
user: "1000:1000" # Usuário não‑root
read_only: true # Sistema de arquivos somente leitura
volumes:
- /tmp/app:/tmp # Monte diretórios específicos se for necessário acesso de escrita
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
Explicação:
- Um sistema de arquivos somente leitura impede alterações dentro do contêiner.
- Garanta que os volumes montados estejam limitados aos diretórios necessários.
2. Isolamento de Rede e Gerenciamento de Portas
Divida de forma precisa redes internas e externas para evitar expor serviços sensíveis ao público:
networks:
frontend:
internal: false
backend:
internal: true
services:
nginx:
networks: [frontend, backend]
database:
networks:
- backend
- Rede frontend: pode ser aberta ao público.
- Rede backend: restrita estritamente, comunicação interna apenas.
3. Gerenciamento Seguro de Segredos
Dados sensíveis nunca devem ser inseridos diretamente em arquivos Compose:
Em modo de máquina única:
services:
webapp:
environment:
- DB_PASSWORD_FILE=/run/secrets/db_password
volumes:
- ./secrets/db_password.txt:/run/secrets/db_password:ro
Em modo Swarm:
services:
webapp:
secrets:
- db_password
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
external: true # Gerenciado pelo gerenciamento nativo do Swarm
Observação:
- Os Segredos nativos do Swarm não podem usar diretamente ferramentas externas como Vault ou AWS Secrets Manager.
- Caso seja necessário armazenamento externo de segredos, integre o processo de leitura por conta própria.
4. Limitação de Recursos (Adaptar à Versão do Docker Compose)
Limites de recursos evitam que um único contêiner esgote os recursos do host.
Modo de Máquina Única (Docker Compose v2.4 recomendado):
version: "2.4"
services:
api:
image: your-image:1.4.0
mem_limit: 512m
cpus: 0.5
Modo Swarm (v3 ou superior):
services:
api:
deploy:
resources:
limits:
cpus: "0.5"
memory: 512M
reservations:
cpus: "0.25"
memory: 256M
Nota: Em ambientes não‑Swarm, a seção
deploycom limites de recursos não tem efeito, portanto, preste atenção à versão do arquivo Compose.
5. Verificações de Saúde dos Contêineres
Configure health checks para detectar problemas proativamente e reduzir o tempo de inatividade:
services:
webapp:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 20s
6. Evitar o Uso da Tag latest
Evite a incerteza trazida pela tag latest em ambientes de produção; imponha versões específicas de imagens:
services:
api:
image: your-image:1.4.0
7. Gerenciamento Adequado de Logs
Impeça que logs de contêineres consumam todo o espaço em disco:
services:
web:
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "5"
8. Configuração do AppArmor no Ubuntu
Por padrão, o Ubuntu habilita o AppArmor, e recomenda‑se verificar o status do perfil Docker:
sudo systemctl enable --now apparmor
sudo aa-status
O Docker no Ubuntu já habilita o AppArmor sem necessidade de configuração adicional. Não é recomendado habilitar o SELinux simultaneamente ao Ubuntu para evitar conflitos.
9. Atualizações Contínuas e Varreduras de Segurança
- Varredura de Vulnerabilidades de Imagens: Recomenda‑se integrar ferramentas como Trivy, Clair ou Snyk ao processo CI/CD:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy image your-image:v1.2.3
- Processo Automatizado de Atualizações de Segurança: Reconstrua imagens pelo menos semanalmente para corrigir vulnerabilidades conhecidas.
III. Estudo de Caso: Lições de Erros de Configuração no Docker Compose
Em julho de 2019, a Capital One sofreu uma grande violação de dados que afetou informações pessoais de mais de 100 milhões de clientes 12. Embora a causa principal fosse erro de configuração na AWS, também envolveram questões de segurança de contêineres semelhantes ao seu cenário:
- Problemas de Permissão em Contêineres: O invasor explorou uma vulnerabilidade em um Web Application Firewall (WAF) rodando em um contêiner com permissões excessivas.
- Isolamento de Rede Insuficiente: O invasor pôde acessar outros recursos da AWS a partir do contêiner comprometido, indicando falta de isolamento de rede adequado.
- Exposição de Dados Sensíveis: Devido a erros de configuração, o invasor conseguiu acessar e roubar grande quantidade de dados confidenciais dos clientes.
- Erros de Configuração de Segurança: A raiz do incidente foi o acúmulo de múltiplos erros de configuração, incluindo falhas em contêineres e serviços de nuvem.
O incidente gerou perdas financeiras significativas e danos à reputação da Capital One. Relata‑se que a empresa enfrentou multas de até US $150 milhões, além de uma crise de confiança de longo prazo. Esse caso evidencia a importância da configuração de segurança em ambientes de contêineres e nuvem, especialmente na gestão de permissões, isolamento de rede e proteção de dados sensíveis. Ele nos lembra que até mesmo pequenos erros de configuração podem ser explorados por atacantes, levando a consequências desastrosas.
IV. Conclusão e Recomendações
Docker Compose combinado com Ubuntu é uma forma prática de implantar rapidamente aplicações containerizadas, mas a segurança deve estar integrada em todo o processo:
- Controle estrito de permissões de contêineres e isolamento de rede.
- Evite vazamento de dados sensíveis.
- Varreduras de segurança regulares e atualizações frequentes.
- Recomenda‑se migrar para sistemas de orquestração avançados como Kubernetes para garantir maior segurança à medida que a empresa escala.
Segurança é uma prática contínua, sem ponto final. Espero que este artigo ajude você a proteger melhor seu ambiente de implantação Docker Compose + Ubuntu.
