Segurança de containers Docker: o guia completo

Os containers mudaram a forma como o software é entregue. Um único docker run dá ao desenvolvedor um ambiente reprodutível em segundos, e a mesma image viaja inalterada do laptop para o CI e para a produção. Essa portabilidade é exatamente por que a segurança de containers Docker merece atenção deliberada: a conveniência que torna os containers fáceis de entregar também torna fáceis de entregar, junto com eles, os padrões inseguros, as base images vulneráveis e os segredos vazados. Este guia percorre o quadro inteiro — o que significa segurança de containers, por que a arquitetura do Docker precisa ser protegida, a superfície de ataque ao longo do ciclo de vida e as práticas que se sustentam em produção.

Segurança de containers Docker é a disciplina de proteger cargas de trabalho conteinerizadas e a infraestrutura em que elas rodam, do build ao runtime. Ela abrange o código e a configuração que definem uma image, a própria image e suas dependências, o registry que a distribui, o host e o daemon que a executam e o comportamento do container em execução. Fazer isso direito significa tratar cada uma dessas coisas como sua própria camada, com seus próprios controles, em vez de supor que um container é uma caixa segura simplesmente porque é um container.

Por que o modelo do Docker precisa ser protegido

O mais importante a entender sobre segurança de containers é o que um container realmente é. Um container não é uma pequena máquina virtual. Uma máquina virtual roda seu próprio kernel em cima de um hypervisor, e esse hypervisor é uma fronteira rígida entre os hóspedes. Um container não tem kernel próprio — todo container em um host compartilha o único kernel Linux do host, e o isolamento é criado por recursos do kernel: os namespaces particionam o que um processo pode enxergar (sua própria árvore de processos, pilha de rede, mounts e usuários), enquanto os control groups (cgroups) limitam o que ele pode consumir (CPU, memória, PIDs).

Esse design é leve e rápido, mas tem uma consequência direta de segurança: a fronteira de isolamento é o kernel, e o kernel é compartilhado. Uma vulnerabilidade no kernel, ou um container com privilégio suficiente para alcançá-lo, pode afetar todos os outros containers do host e o próprio host. É por isso que um "container escape" é um evento tão sério e por que a frase "containers não são uma fronteira de segurança do jeito que as VMs são" é repetida com tanta frequência. Não é que containers sejam inseguros — containers bem configurados são fortemente isolados — mas o teto desse isolamento é mais baixo que o de um hypervisor, então a configuração importa mais.

Dois padrões agravam isso. Primeiro, os processos dentro de um container rodam como root por padrão e, a menos que você intervenha, o root dentro do container mapeia para o root no host. Se um atacante escapar, ele escapa como um usuário privilegiado. Segundo, aquilo que orquestra tudo isso — o daemon Docker (dockerd) — roda como root e escuta em um socket Unix. Qualquer um que consiga falar com esse socket pode iniciar um container que monta o sistema de arquivos do host e, a partir daí, dominar a máquina. O daemon é uma fronteira de confiança, e o acesso a ele é, na prática, root no host. Tenha ambos em mente; quase toda recomendação de hardening que segue remonta a eles.

A superfície de ataque do container ao longo do ciclo de vida

Ajuda mapear o risco às etapas pelas quais uma image passa, porque os controles diferem em cada etapa e uma brecha em qualquer uma delas mina as outras. O ciclo de vida percorre: build, image, registry, host e daemon, e runtime. As seções abaixo resumem cada um e apontam para o aprofundamento que o cobre por inteiro.

Build: o Dockerfile

A segurança começa com o Dockerfile, porque o Dockerfile decide o que acaba na image e como o container roda. As escolhas aqui são grudentas — elas embarcam em cada pull e em cada deploy. Uma linha FROM que fixa uma base image gorda e desatualizada embute centenas de pacotes que você nunca vai usar, mas terá de corrigir. Rodar tudo como root, instalar um gerenciador de pacotes completo e um shell em uma image de produção, usar a tag mutável latest em vez de um digest fixado e copiar todo o build context com um descuidado COPY . . — tudo isso alarga a superfície antes mesmo de o container começar.

As soluções são igualmente concretas: escolha base images mínimas ou distroless, adicione um USER não-root dedicado, use multi-stage builds para que o ferramental de build nunca alcance a image final, fixe versões e digests para reprodutibilidade e use um .dockerignore para manter segredos e lixo local fora do context. Para o checklist completo, veja Dockerfile security best practices.

Image: base image, dependências, segredos e proveniência

A image é onde a maior parte do risco explorável de fato vive, porque uma image é uma pilha de camadas contendo um sistema operacional, runtimes de linguagem e as dependências da sua aplicação — qualquer uma das quais pode carregar vulnerabilidades conhecidas. Uma base image que estava atualizada no momento do build fica defasada em questão de semanas. As dependências da aplicação puxadas de registries públicos trazem sua própria árvore transitiva de pacotes, e essa cadeia de suprimentos é um alvo primário: o OWASP Top 10 2025 eleva as falhas de cadeia de suprimentos de software à categoria A03, refletindo o quão frequentemente o comprometimento hoje chega pelas dependências e pipelines de build, e não pelo código da aplicação em si.

A proveniência importa tanto quanto o conteúdo. Você consegue provar que uma image foi construída a partir do código-fonte que você acha que foi, pelo pipeline em que você confia, e que ela não foi adulterada desde então? É aí que entram um software bill of materials (SBOM), as attestations de build e a assinatura de image. Fazer scan de images com software composition analysis expõe os componentes com vulnerabilidades conhecidas; os controles de proveniência tornam a image confiável. Veja Docker image security e software composition analysis para o tratamento completo.

Registry: distribuição e assinatura

Entre o build e a execução fica o registry, o ponto de distribuição das suas images e, portanto, um elo de alto valor na cadeia. Um registry que permite pushes anônimos, carece de controle de acesso ou serve images não assinadas deixa um atacante substituir uma image legítima por uma maliciosa, e cada host que a puxa executa o código do atacante. A segurança de registry gira em torno de autenticação forte e acesso de menor privilégio, de assinar images e verificar essas assinaturas no pull, de fazer scan de images no push para que um build vulnerável nunca se torne disponível para pull, e de limpar tags obsoletas que silenciosamente permanecem como superfície de ataque. Veja container registry security.

Host e daemon: rootless, exposição do socket e controles de kernel

O host é a base compartilhada, e o daemon é seu componente mais sensível. O erro de host mais comum e mais danoso é expor o socket do Docker — montar /var/run/docker.sock dentro de um container ou, pior, vincular o daemon a uma porta TCP sem TLS mútuo. Qualquer um dos dois entrega root. Não faça nenhum dos dois: mantenha o socket fora da rede e nunca o monte dentro de um container, a menos que você confie plenamente nesse container e o controle.

Além do socket, o host é onde as primitivas de isolamento do kernel são ajustadas. As capabilities do Linux permitem descartar os amplos poderes que o root normalmente detém e conceder de volta apenas o que uma carga de trabalho precisa, de modo que um processo comprometido não consiga, digamos, carregar módulos de kernel ou alterar a propriedade arbitrária de arquivos. Um profile de seccomp restringe quais system calls um container pode fazer, encolhendo a superfície de kernel que um escape poderia mirar; o Docker vem com um profile de seccomp padrão sensato, e você pode apertá-lo. O AppArmor (ou o SELinux) adiciona controle de acesso mandatório por cima. E o Docker rootless roda o daemon e os containers como um usuário sem privilégios, de modo que até um breakout desemboca como um usuário não-root no host, e não como root — uma redução significativa do raio de impacto. Combine isso com limites de cgroup por container para que uma única carga de trabalho não consiga exaurir os recursos do host.

Runtime: drift, escapes e monitoramento

Tudo acima diz respeito ao estado de um container antes de ele rodar. A segurança de runtime diz respeito ao seu comportamento uma vez que está no ar. As images deveriam ser imutáveis, mas os containers em execução sofrem drift — um pacote é instalado manualmente, um arquivo de configuração é editado, um shell fica aberto, um processo que nunca esteve na image começa a rodar. O drift é ao mesmo tempo um mau cheiro operacional e um sinal de segurança: um container fazendo algo que sua image nunca descreveu merece ser investigado. O runtime também é onde aparecem tentativas de escape, escalonamento de privilégios, conexões de saída inesperadas e cripto-mineração. As defesas são monitorar o comportamento do container contra uma linha de base esperada, impor sistemas de arquivos raiz somente leitura onde possível, alertar sobre drift e atividade anômala de processo ou de rede, e ter um caminho de resposta quando algo dispara. Veja container runtime security.

Segredos em containers: build args, env e vazamento por camadas

Os segredos merecem seu próprio aviso porque os erros são tão fáceis de cometer e tão difíceis de desfazer. Três padrões vazam credenciais, e os três são comuns.

Primeiro, os build arguments. Valores passados com --build-arg e referenciados via ARG ficam visíveis no histórico da image — o docker history vai mostrá-los — então uma chave de API passada como build arg está, na prática, publicada dentro da image. Segundo, as variáveis de ambiente. Embutir um segredo em uma instrução ENV o armazena em uma camada da image que qualquer um com a image pode ler; injetar segredos como variáveis de ambiente em runtime é melhor do que embuti-los, mas as env vars ainda ficam visíveis para qualquer processo no container e, muitas vezes, para logs e relatórios de erro. Terceiro, as camadas. Como cada instrução do Dockerfile cria uma camada, copiar um segredo e depois apagá-lo em uma instrução posterior não o remove — o arquivo ainda existe na camada anterior, e qualquer um pode desempacotar a image para encontrá-lo.

A regra é simples: não coloque segredos em images. Use secret mounts em tempo de build (o --mount=type=secret do BuildKit), que nunca persistem em uma camada, injete segredos de runtime através de um gerenciador de segredos dedicado, e faça scan de images e Dockerfiles em busca de credenciais commitadas por acidente como parte do CI. Trate como comprometido qualquer segredo que um dia tenha tocado uma camada de image, e faça a rotação dele.

A relação com o Kubernetes

A segurança de containers Docker e a segurança do Kubernetes estão relacionadas, mas não são a mesma coisa, e vale ser preciso quanto à fronteira. Tudo neste guia é sobre o container em si — como ele é construído, o que há nele, como é distribuído e como o host o roda. O Kubernetes fica uma camada acima: ele orquestra containers por uma frota de hosts, agendando-os, conectando-os em rede, escalando-os e gerenciando sua configuração e seus segredos em escala. Os containers que o Kubernetes roda são as mesmas images e as mesmas preocupações de runtime descritas aqui — uma image vulnerável é vulnerável quer você a rode com docker run, quer um agendador o faça — então a segurança de containers é a fundação sobre a qual a segurança do Kubernetes é construída.

O que o Kubernetes acrescenta é sua própria superfície de ataque: o API server e o RBAC, o admission control de cargas de trabalho, os pod security standards, as network policies entre serviços e o tratamento de segredos em nível de cluster. Isso pertence à camada de orquestração, e a cobrimos separadamente para que este guia não a duplique. Se você roda containers no Kubernetes, leia Kubernetes security junto com este guia, e Kubernetes image security para saber como os controles de image se estendem para dentro do cluster. O admission control é onde os dois mundos se encontram: é o portão do cluster que pode recusar uma image que falhou nas suas verificações das etapas de build e registry.

Shift left: pegue os problemas antes que eles rodem

O lugar mais barato para corrigir um problema de segurança de container é antes de a image ser construída, e o segundo mais barato é antes de ela ser implantada. Deslocar para a esquerda (shift left) significa mover essas verificações para dentro do fluxo de trabalho do desenvolvedor e do pipeline de CI, em vez de descobrir os problemas em produção. Na prática isso se parece com: fazer lint e scan de Dockerfiles em busca de instruções inseguras à medida que o código é escrito, rodar software composition analysis em cada build para que dependências vulneráveis reprovem o pipeline, fazer scan da image finalizada em busca de CVEs de OS e de bibliotecas e de segredos embutidos, gerar um SBOM e assinar a image, e aplicar política em um portão de registry ou de admission para que uma image não conforme não possa ser promovida.

A mesma disciplina se estende ao ambiente em que os containers rodam. Os hosts de container e a orquestração são cada vez mais definidos como código — Dockerfiles, arquivos Compose e templates de infraestrutura — então fazer scan dessa configuração pega as configurações incorretas (um container privilegiado, um socket montado, um limite de recurso ausente) antes que sejam provisionadas. Veja IaC security para esse lado do quadro. O shift left não substitui a defesa de runtime; ele reduz o quanto chega ao runtime, para que o seu monitoramento tenha menos coisas, e mais significativas, a pegar.

Boas práticas

Juntando os fios, uma postura forte de segurança de containers Docker se apoia em um conjunto consistente de hábitos:

• Comece a partir de base images mínimas, confiáveis e regularmente atualizadas, e fixe-as por digest em vez de uma tag flutuante.
• Rode containers como um usuário não-root, descarte todas as capabilities do Linux e adicione de volta apenas o que é necessário, e mantenha o sistema de arquivos raiz somente leitura onde a carga de trabalho permitir.
• Nunca exponha o socket do daemon Docker a um container ou à rede, e prefira o Docker rootless para encolher o raio de impacto de qualquer escape.
• Mantenha o profile de seccomp padrão no lugar (ou aperte-o), e coloque AppArmor ou SELinux por cima para controle de acesso mandatório.
• Mantenha segredos totalmente fora das images — use secret mounts de build e um gerenciador de segredos de runtime, e faça scan em busca de credenciais vazadas.
• Faça scan de images e dependências continuamente, gere um SBOM e assine as images para que a proveniência possa ser verificada no pull.
• Defina limites de recursos de cgroup para que um container não consiga sufocar o host, e monitore os containers em execução em busca de drift e comportamento anômalo.
• Aplique tudo isso como política automatizada no CI e nos portões de registry ou de admission, não como uma etapa de revisão manual.

Como a Rainforest ajuda

Proteger containers é um problema de ciclo de vida completo, e é por isso que é difícil resolvê-lo com ferramentas pontuais aparafusadas no fim. A Rainforest traz a segurança de image de container e a software composition analysis para dentro de uma única plataforma de segurança de aplicações, de modo que as mesmas verificações que fazem scan do código da sua aplicação também inspecionam as images que você entrega: pacotes de OS e dependências com vulnerabilidades conhecidas, segredos embutidos e configuração insegura de image, expostos no pipeline onde os desenvolvedores podem agir sobre eles, em vez de em um console separado depois do fato. Como ela roda no CI e gera os dados de proveniência — SBOMs e resultados de scan — dos quais os portões seguintes dependem, os achados chegam com o contexto para priorizá-los e corrigi-los, e a mesma política acompanha a image do build, passando pelo registry, até o ponto de deploy.

Se você quer ver onde as images de container da sua organização estão hoje, book a demo ou explore container security dentro da plataforma mais ampla de application security testing.