Os principais erros de segurança do Docker que você deve evitar em 2026

Você pode rodar Docker em produção por meses sem problemas visíveis. Containers iniciam, aplicações respondem, nada quebra. Então uma porta exposta ou uma permissão mal configurada cria um ponto de entrada que um atacante não precisaria conquistar. A maioria dos erros de segurança em Docker não parecem erros até algo dar errado.

Este artigo cobre as configurações específicas que colocam ambientes de container em risco, o que cada uma permite para um atacante, e termina com um checklist que você pode rodar contra sua própria infraestrutura hoje.

Por Que a Segurança do Docker É Mais Complexa do Que Parece

Containers parecem isolados. Você inicia um, ele executa seu próprio espaço de processo, e de dentro dele, o próximo container não existe. Você consegue isolamento, mas é apenas parcial. Containers compartilham o kernel do host, o que significa que um processo dentro de um container pode, sob condições específicas, alcançar o sistema host completamente.

Docker é configurado para conveniência do desenvolvedor, não para endurecimento de produção. Acesso root ativado. Todas as portas podem se vincular a todas as interfaces. Nenhum monitoramento em tempo de execução. A maioria dos desenvolvedores aceita essas configurações, implanta o container e segue adiante. É uma abordagem razoável para começar, mas não é uma postura de segurança completa.

De acordo com Relatório 2024 Red Hat State of Kubernetes Security, 67% das organizações atrasaram ou reduziram a velocidade da implantação de aplicações devido a preocupações de segurança de container ou Kubernetes. Esse atrito geralmente não vem de ataques. Vem de equipes descobrindo que suas configurações de container precisavam de endurecimento que não tinham implementado.

Frequentemente vemos containers rodando em produção com a mesma configuração que tinham no computador local de um desenvolvedor. É aí que os erros de segurança em Docker tendem a se acumular silenciosamente, sem sintomas visíveis até algo ser auditado ou falhar.

Os erros que criam essas lacunas são específicos, previsíveis e em sua maioria evitáveis, começando no nível de configuração.

Erros Comuns de Configuração do Docker

A maioria das brechas de container não começa com um exploit zero-day. Começam com uma configuração definida no primeiro dia, sem muito pensamento sobre exposição de rede ou escopo de privilégio.

As configurações padrão do Docker são feitas para funcionar. A diferença entre funcional e seguro é onde os riscos de segurança de container do Docker se acumulam, especialmente em instalações self-hosted que são implantadas e nunca revisitadas.

Vemos esse padrão frequentemente: containers em servidores com IP público com bindings de porta, configurações de usuário e configurações de rede exatamente como estavam na implantação inicial.

Executar Containers como Root

Quando você inicia um container Docker sem especificar um usuário, ele executa como root. Isso significa que qualquer processo dentro do container, incluindo sua aplicação, tem privilégios de nível root dentro do namespace do container.


Root dentro de um container não é a mesma coisa que root no host, mas a separação não é absoluta. Exploits de escalação de privilégio direcionados ao runtime, como o bem documentado runc CVE-2019-5736 e falhas de runtime similares, frequentemente requerem um processo container com root para ter sucesso.

Containers não-root removem o requisito de processo root que esses exploits dependem, reduzindo significativamente a superfície de ataque para essa classe de vulnerabilidade, embora não eliminem completamente o risco de escape de container.

Adicionar uma diretiva USER ao seu Dockerfile resolve isso. Algumas imagens oficiais vêm com um usuário sem privilégios que você pode ativar com uma diretiva USER, mas muitas ainda usam root como padrão sem um usuário de aplicação pronto. Nesses casos, você cria o usuário no Dockerfile antes de alternar para ele. Para a maioria das instalações self-hosted, essa mudança única remove uma categoria inteira de risco de escalação.

Expor Muitas Portas para a Internet Pública

Quando você publica uma porta com Docker, Docker escreve suas próprias regras de iptables diretamente. Essas regras são executadas antes das regras de firewall no nível do host. Esse é um comportamento bem conhecido reportado pela comunidade e documentado no guia de filtro de pacotes do Docker, não uma misconfiguration, e significa que UFW e ferramentas similares não bloqueiam o que Docker já abriu.

Docker escreve diretamente nas iptables, contornando as configurações padrão do UFW e firewalld em muitos hosts Linux. Isso significa que uma porta vinculada a 0.0.0.0 pode ser acessível publicamente mesmo quando seu firewall parecer estar configurado. Os grupos de segurança da cloud e as regras da cadeia DOCKER-USER ainda podem bloquear esse tráfego, então a exposição real depende da sua configuração de rede específica.

Vincule serviços a 127.0.0.1 sempre que possível, roteie o tráfego voltado para o público através de um proxy reverso e publique apenas o que genuinamente requer acesso externo. Um proxy reverso é a forma mais confiável de controlar o que fica exposto de fora do host.

Ignorar Isolamento de Rede Entre Containers

Qualquer container nessa rede pode alcançar qualquer outro container nela sem restrição. O bridge padrão não aplica filtragem de tráfego entre containers que o compartilham, e a maioria das configurações nunca muda isso.

Se um container for comprometido, essa comunicação aberta se torna um caminho de movimento lateral. Um container de frontend pode alcançar um banco de dados, um API interno, ou qualquer outra coisa na mesma rede bridge padrão, mesmo quando esse acesso nunca foi pretendido.

Redes definidas pelo usuário lhe dão controle explícito sobre quais containers podem se comunicar, mas uma única rede customizada compartilhada por todos os seus serviços ainda permite tráfego livre entre containers. O isolamento real exige colocar serviços que não deveriam se comunicar em redes separadas. Desativar o bridge padrão é o ponto de partida, não a linha de chegada.

Negligenciar o Socket Docker

O socket Docker em /var/run/docker.sock é a interface de controle para todo o motor Docker. Montá-lo em um container dá a esse container acesso direto API ao daemon executando no host.

Com esse acesso, um container pode iniciar novos containers, montar diretórios do host, inspecionar e modificar containers em execução, e efetivamente controlar a máquina host. A superfície de ataque é equivalente a root no host, por isso qualquer ferramenta que exija acesso ao socket merece avaliação cuidadosa.

Para a maioria dos casos de uso, existem alternativas mais seguras: APIs com escopo ou ferramentas de gerenciamento Docker que não exigem acesso ao socket. Docker-em-Docker tem suas próprias compensações de segurança e operacional e não é um substituto direto.

Erros de configuração criam a exposição inicial. As escolhas de imagem e dependência determinam como essa exposição se agrava ao longo do tempo.

Erros de Imagem e Secrets Que Perduram Além do Container

Quando você para um container, os erros de configuração dentro dele param com ele. Quando você reconstrói a partir de uma imagem que traz uma vulnerabilidade ou uma credencial hardcoded, o problema reinicia com o container. Erros no nível de imagem não são redefinidos entre deploys.

Eles viajam com a imagem para cada ambiente que a puxa, cada registro que a armazena, e cada membro da equipe que a executa. Essa persistência faz do gerenciamento de imagem e secrets uma categoria de risco distinta, que merece auditoria separada da configuração.

Vemos esse padrão frequentemente: uma imagem escolhida com cuidado no início do projeto e nunca reconstruída desde então, derivando lentamente da baseline de segurança que representava inicialmente.

Usar Imagens Não Confiáveis ou Desatualizadas

Registros públicos estão abertos para qualquer um. Imagens maliciosas foram distribuídas através do Docker Hub carregando crypto-miners e backdoors incorporados no histórico de camadas que persistem através de reinicializações de container. Verificação antes de puxar importa, especialmente para imagens de publicadores desconhecidos ou não oficiais.

O problema separado é o envelhecimento. Uma imagem oficial que você puxou há seis meses e nunca reconstruiu desde então vem acumulando vulnerabilidades Docker sem patch a cada CVE divulgado contra seus pacotes. A imagem não está quebrada. Ela simplesmente não é mais atual.

Relatório 2024 State of the Software Supply Chain da Sonatype descobriu que 95% das vezes um componente vulnerável é consumido, uma versão corrigida já está disponível, e 80% das dependências de aplicação permanecem não atualizadas por mais de um ano. Esse padrão é relevante para imagens base Docker também, já que elas dependem dos mesmos pacotes open-source.

Use imagens oficiais de editores verificados e fixe versões específicas com tags ao invés de depender de "latest". Estabeleça um cronograma regular de reconstrução para manter suas imagens atualizadas.

Armazenar Secrets em Arquivos Docker e Compose

Credenciais escritas em uma instrução ENV ou ARG do arquivo Docker, codificadas em um bloco de ambiente do Compose, passadas como argumentos de construção, ou armazenadas em um arquivo .env com commit no controle de versão não desaparecem quando você para o container. Elas ficam no histórico de camadas da imagem ou no controle de versão, acessíveis para qualquer pessoa que consiga alcançá-las.

Este é um dos erros de segurança do Docker mais negligenciados porque não causa problemas visíveis durante o desenvolvimento. Uma chave API em uma instrução ENV funciona corretamente. Ela também está no seu repositório, embutida na sua imagem, e distribuída para qualquer lugar que essa imagem vá.

O Compose moderno Docker oferece um mecanismo nativo de secrets que monta credenciais em tempo de execução sem incorporá-las à imagem. Os secrets API do Docker e gerenciadores externos de secrets seguem o mesmo princípio. Estas são as opções que mantêm credenciais completamente fora de artefatos de construção e arquivos com commit.

Variáveis de ambiente em tempo de execução são uma melhoria em relação a credenciais codificadas, mas ainda ficam expostas através da saída do inspect Docker, logs e crash dumps. São um passo adiante em relação a secrets incorporados, não uma solução completa.

Não Atualizar Container Images Regularmente

Executar a mesma imagem por meses é um hábito comum. A cada dia que passa após uma nova vulnerabilidade ser divulgada, mas antes de você reconstruir, seus containers carregam uma janela de exposição que cresce sem nenhuma mudança visível.

Estabeleça um cronograma consistente de reconstrução. Automatize esse processo quando possível, e execute um scanner de vulnerabilidades periodicamente contra suas imagens atuais. O objetivo não é perfeição. É reduzir o tempo entre um patch ser lançado e ser implantado.

Controle de acesso e monitoramento podem ser deprioritizados em implantações rápidas. Também são as categorias onde incidentes ficam sem detecção por mais tempo.

Controle de Acesso e Lacunas de Visibilidade

Após um container estar em execução com uma configuração sólida e imagens atuais, duas categorias de falha permanecem. Ambas são invisíveis por natureza: você não vai notar um problema de controle de acesso fraco até alguém usá-lo, e você não vai notar uma lacuna de monitoramento até precisar investigar uma atividade que nunca foi registrada.

O mesmo Pesquisa Red Hat 2024 constatou que 42% das equipes careciam de capacidades suficientes para lidar com segurança de containers e ameaças relacionadas.

Descobrimos que lacunas de monitoramento geralmente aparecem durante investigações de incidentes, não antes. Quando a visibilidade se torna uma prioridade, geralmente é em resposta a algo ao invés de preveni-lo.

Autenticação Fraca e Dashboards de Gerenciamento Expostos

Um dashboard de gerenciamento de containers em um IP público sem autenticação não requer um atacante sofisticado. Requer apenas que ele saiba o endereço. Essa é uma barra mais baixa do que a maioria das equipes percebe.

Ferramentas de monitoramento e gerenciamento auto-hospedadas geralmente vêm com uma interface web acessível em todas as interfaces de rede. Deixar essas em um IP público sem autenticação na frente delas é o equivalente em containers de deixar um painel de admin desbloqueado.

Autenticação, um reverse proxy, e posicionamento em rede privada são o mínimo. Controle de acesso é uma etapa de configuração que você adiciona a qualquer interface de gerenciamento, não algo que vem ativado.

O mesmo princípio se aplica a gerenciamento CLI e GUI do Docker; acesso de nível admin ao daemon carrega o mesmo risco independentemente da interface.

Não Monitorar O Que Seus Containers Estão Fazendo

Se um container for comprometido, a atividade do invasor deixa rastros: mudanças no comportamento de processos, conexões de rede incomuns e modificações inesperadas de arquivos. Sem coleta de logs, esse rastro não existe em um formato que você possa usar.

Coleta centralizada de logs, auditoria de containers e ferramentas de monitoramento de runtime oferecem os dados necessários para detectar atividades anormais antes que se agravem. O objetivo não é analisar cada linha. É ter os dados disponíveis quando precisar investigar.

Setups de container que rodam silenciosamente em produção sem pipeline de logs e sem alertas não são de baixa manutenção. São inspeventos. São dois estados operacionais diferentes.

Por Que o Ambiente de Infraestrutura Também Importa

Segurança de container começa com configuração, mas a configuração roda sobre infraestrutura. Um host com networking mal configurado, recursos compartilhados ou sem filtragem de rede no nível de infraestrutura cria condições que afetam cada container acima dele. Acertar o setup de container e acertar a configuração do servidor são duas tarefas separadas.

Muitas lacunas de segurança em Docker são amplificadas por condições que os próprios containers herdam:

• Um servidor de múltiplos clientes sem isolamento de hardware entre eles
• Um kernel do host rodando sem patches
• Um host sem filtragem de rede integrada no nível de infraestrutura

Isso não elimina a necessidade dos passos de configuração acima, pois o hardening adequado de container importa independentemente da camada de infraestrutura. Começar em infraestrutura isolada remove uma camada de preocupação da equação.

Na Cloudzy, oferecemos dois caminhos dependendo do que seu setup requer:

• Linux VPS: um ambiente limpo para você deployar Docker e aplicar os passos de hardening deste artigo
• Portainer VPS: uma opção com um clique que vem com Portainer pré-instalado; o servidor inicia e você já está no painel de controle

Ambas as opções rodam na mesma infraestrutura: virtualização KVM, AMD Ryzen 9 CPUs com boost de até 5,7 GHz, memória DDR5, armazenamento NVMe SSD, rede de até 40 Gbps e proteção contra DDoS DDoS via BuyVM, em 12 locais globais com SLA de 99,95%.

Para saber mais sobre como rodar Portainer em um VPS, confira nosso artigo dedicado.

Um Checklist Prático de Segurança para Deployments de Docker

A maioria dos erros de segurança em Docker acima vêm de decisões de configuração únicas feitas uma vez e nunca revisitadas. Executar este checklist contra um setup existente identifica essas lacunas. Funciona como uma auditoria, não como um guia de deployment.

Essas práticas de segurança para Docker cobrem como proteger containers Docker contra as falhas de configuração mais comuns descritas acima.

Referência Rápida: Os 9 Erros

Recomendamos executar contra configurações existentes primeiro, pois é onde as lacunas provavelmente já estão presentes.

Containers em execução como usuário não-root: Verifique seus Dockerfiles para uma diretiva USER. Se não existir, o container é executado como root.

Vinculações de porta limitadas a localhost ou proxies: Execute docker ps e revise as vinculações de porta. Uma entrada 0.0.0.0:PORT pode ser alcançável publicamente em hosts onde nenhum security group upstream, firewall externo ou regra da chain DOCKER-USER a bloqueia.

Redes bridge customizadas em uso: Containers na bridge padrão do Docker podem alcançar uns aos outros livremente. Containers na mesma bridge definida pelo usuário ainda conseguem se comunicar, então distribua serviços em redes separadas por limite de confiança para isolamento real.

Socket do Docker não montado em containers: Verifique os arquivos Compose e argumentos de execução. Se /var/run/docker.sock aparece como volume, confirme se é necessário e intencional.

Imagens base de editores verificados com versões fixas: Um FROM ubuntu:latest puxa uma versão não especificada e potencialmente desatualizada. Fixe uma versão específica.

Sem segredos em Dockerfiles, arquivos Compose ou argumentos de build: O histórico de camadas da imagem persiste credenciais após exclusão do container. Use Compose secrets, Swarm secrets, build secret mounts ou um gerenciador de segredos externo. Variáveis de ambiente em tempo de execução são melhores que valores codificados, mas ainda aparecem na saída de inspect e logs.

Agenda de reconstrução de imagem definida: Imagens antigas acumulam vulnerabilidades. Uma cadência de reconstrução mensal mantém a janela de exposição gerenciável para a maioria das configurações.

Interfaces de gerenciamento protegidas por autenticação: Qualquer dashboard em um IP público sem autenticação é um ponto de entrada aberto. Colocação em rede privada é preferível onde possível.

Logs de contêiner sendo coletados: Sem um pipeline de logs, a detecção de incidentes depende do impacto visível do sistema. É um sinal tardio para agir.

Conclusão

A configuração padrão do Docker é feita para conveniência, não segurança. A maioria dos erros cobertos neste artigo volta a configurações que nunca foram alteradas após a implantação inicial, não a ataques sofisticados.

As correções são principalmente decisões de configuração únicas: uma diretiva USER, uma mudança de ligação de porta, uma rede personalizada, um cronograma de reconstrução. Nenhuma delas requer novas ferramentas para a maioria das configurações.

Acertar a configuração do contêiner é a primeira tarefa. A infraestrutura em que ele é executado é a segunda. Ambas importam, e nenhuma substitui a outra.

Perguntas Frequentes