Hardening de Container: 10 Práticas Para Não Rodar Root em Produção

Há uma ilusão confortável de que containers são seguros por isolarem processos. A realidade é mais dura: containers compartilham o kernel do host e, na configuração padrão, oferecem um isolamento bem mais fraco do que uma máquina virtual. Um container mal configurado — rodando como root, com o filesystem gravável, com capabilities do kernel que não usa — é uma porta convidativa para que uma falha na aplicação vire comprometimento do host inteiro e, dali, dos containers vizinhos.

Hardening de container é o conjunto de práticas que reduzem essa superfície de ataque, aplicando o princípio do menor privilégio em cada camada: a imagem, o runtime, as permissões, a rede. Nenhuma prática isolada é uma bala de prata; a segurança vem da soma delas, em profundidade. Aqui vão dez que separam um container de produção sério de um acidente esperando acontecer.

1. Nunca rode como root

Por padrão, processos dentro de um container rodam como root (UID 0). Se um atacante explora uma falha na aplicação, ele ganha privilégios de root dentro do container — e, dependendo de outras brechas, isso pode escalar para o host. A correção é direta e é a mais importante da lista: crie e use um usuário não privilegiado.

``dockerfile FROM debian:12-slim # Cria um usuário sem privilégios e sem shell de login. RUN useradd --system --no-create-home --shell /usr/sbin/nologin app # ... copia a aplicação ... USER app # a partir daqui, o processo roda como 'app' ENTRYPOINT ["/usr/local/bin/meu-servico"] ``

Reforce isso no runtime para que nem por engano o container suba como root:

``yaml securityContext: runAsNonRoot: true # o Kubernetes recusa o pod se tentar rodar como root runAsUser: 10001 ``

2. Comece de uma imagem base mínima

Cada pacote na imagem é código que pode ter uma vulnerabilidade. Uma imagem baseada numa distribuição completa carrega centenas de binários e bibliotecas que sua aplicação nunca usa, mas que ampliam a superfície de ataque. Prefira bases mínimas: variantes slim, Alpine, ou imagens distroless, que contêm apenas o runtime da linguagem e as dependências, sem shell, sem gerenciador de pacotes, sem utilitários.

Menos binários significam menos CVEs para corrigir e menos ferramentas à mão de um atacante que consiga entrar. Um container sem sh, curl ou wget dificulta enormemente a vida de quem quer baixar um payload ou explorar o ambiente depois de uma invasão inicial.

3. Use multi-stage build para não vazar ferramentas de build

Compiladores, gerenciadores de pacotes e ferramentas de build não têm nenhuma razão para existir na imagem final de produção. O multi-stage build separa o ambiente de compilação do ambiente de execução, copiando para a imagem final apenas o artefato pronto.

```dockerfile # Estágio de build: tem o compilador e o SDK completo. FROM golang:1.22 AS build WORKDIR /src COPY . . RUN CGO_ENABLED=0 go build -o /app/servico ./cmd/servico

# Estágio final: distroless, só o binário. Nada de compilador. FROM gcr.io/distroless/static:nonroot COPY --from=build /app/servico /servico USER nonroot:nonroot ENTRYPOINT ["/servico"] ```

A imagem final não tem Go, não tem shell, não tem nada além do binário estático e o usuário não-root. É pequena, rápida de distribuir e drasticamente mais difícil de explorar.

4. Deixe o filesystem read-only

Uma aplicação bem-comportada raramente precisa escrever no próprio filesystem em runtime. Tornar o filesystem do container somente-leitura impede que um atacante grave binários maliciosos, modifique a aplicação ou persista uma backdoor.

```yaml securityContext: readOnlyRootFilesystem: true # Para os poucos diretórios que precisam de escrita, monte volumes efêmeros: volumeMounts:

• name: tmp

mountPath: /tmp volumes:

• name: tmp

emptyDir: {} # escrita vai para um volume em memória, não na imagem ```

Se a aplicação precisa escrever, ela escreve em volumes explícitos e controlados, não no filesystem base. Isso também deixa claro, na configuração, exatamente onde a escrita é permitida — qualquer tentativa fora dali falha.

5. Descarte as Linux capabilities que não usa

O root do Linux não é monolítico; ele é dividido em capabilities — permissões granulares como "abrir portas privilegiadas", "mudar o dono de arquivos", "manipular a rede". Por padrão, containers recebem um conjunto de capabilities que a maioria das aplicações nunca usa. Descartar todas e adicionar de volta apenas as estritamente necessárias fecha um vetor inteiro de escalonamento.

``yaml securityContext: capabilities: drop: ["ALL"] # remove todas add: ["NET_BIND_SERVICE"] # devolve só o que precisa (ex.: bind na porta 80) allowPrivilegeEscalation: false ``

O allowPrivilegeEscalation: false complementa: impede que um processo ganhe mais privilégios do que o pai, bloqueando truques com binários setuid.

6. Nunca use o modo privilegiado

O modo privilegiado (privileged: true) dá ao container acesso praticamente total ao host — todos os devices, todas as capabilities. É a antítese do hardening. Salvo casos raríssimos e muito bem justificados (alguns agentes de infraestrutura), um container de aplicação nunca deve ser privilegiado. Se você se pegou usando o modo privilegiado para "resolver" um problema de permissão, quase certamente existe uma capability específica que resolve o mesmo sem abrir o host inteiro.

7. Escaneie imagens em busca de vulnerabilidades

As dependências da sua imagem — a base, as bibliotecas do sistema, os pacotes da linguagem — ganham CVEs novos o tempo todo. Uma imagem segura hoje tem uma vulnerabilidade conhecida amanhã. Scanners de vulnerabilidade de container analisam a imagem, listam os pacotes e cruzam com bancos de CVEs conhecidos.

Integre o scan ao pipeline de CI: nenhuma imagem sobe para produção sem passar por uma verificação, e vulnerabilidades críticas quebram o build. Complemente com reescaneamento periódico das imagens já em produção, porque o CVE novo aparece depois que a imagem já subiu. E mantenha as bases atualizadas — uma imagem que não é reconstruída há meses acumula vulnerabilidades corrigidas que você simplesmente não aplicou.

8. Não coloque segredos na imagem

Chaves, senhas e tokens jamais devem ser embutidos na imagem — nem via ENV, nem copiados como arquivo, nem passados como argumento de build. A imagem é distribuída, armazenada em registries e cacheada em camadas; um segredo dentro dela vaza para todo mundo com acesso à imagem, e permanece no histórico de camadas mesmo se você "apagar" em uma camada posterior.

```dockerfile # ERRADO: o segredo vira parte da imagem, para sempre. ENV API_KEY="sk-1234567890abcdef"

# CERTO: a imagem não conhece o segredo; ele é injetado em runtime # pela plataforma (Secret montado como arquivo ou variável de ambiente). ```

Segredos entram em runtime, vindos de um cofre ou de um Secret da plataforma, idealmente montados como arquivo em memória. A imagem em si deve ser publicável sem vazar nada.

9. Fixe versões e verifique a proveniência

Uma imagem base referenciada como :latest é um alvo móvel: o que você testou hoje pode ser outra coisa amanhã, e um comprometimento upstream entra no seu pipeline sem aviso. Fixe as tags e, melhor ainda, fixe o digest (o hash imutável da imagem), garantindo que você roda exatamente o que auditou.

``dockerfile # Fixa o conteúdo exato pelo digest, imune a mudanças na tag. FROM debian:12-slim@sha256:a1b2c3... ``

No mesmo espírito, prefira imagens de fontes confiáveis e considere verificar assinaturas de proveniência, para ter certeza de que a imagem que você puxou é a que o publicador realmente produziu, e não uma versão adulterada.

10. Limite recursos e isole em runtime

Um container sem limites de CPU e memória pode, sob falha ou ataque, consumir todos os recursos do host e derrubar os vizinhos — um DoS acidental ou intencional. Definir limites de recursos é hardening tanto de segurança quanto de estabilidade.

``yaml resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "256Mi" # o container é morto se estourar, sem afetar os outros ``

Complemente com isolamento adicional onde a criticidade justificar: perfis de seccomp que restringem quais chamadas de sistema o container pode fazer, políticas de rede que limitam com quem cada pod fala, e — para cargas de altíssimo risco ou multi-tenant — runtimes de sandbox que dão isolamento mais forte que o compartilhamento direto do kernel.

Um bônus: reduza a superfície além do container

Duas práticas complementares fecham lacunas que os dez itens anteriores tocam de leve. A primeira é o isolamento de rede. Por padrão, em muitos clusters, qualquer pod fala com qualquer outro pod. Isso significa que um container comprometido pode varrer a rede interna e atacar serviços vizinhos livremente. Políticas de rede que aplicam o menor privilégio também na comunicação — cada serviço só fala com quem precisa falar — contêm o movimento lateral de um atacante que conseguiu o primeiro pé dentro.

``yaml # Nega todo tráfego de entrada por padrão; libera só o necessário em outra policy. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress spec: podSelector: {} policyTypes: ["Ingress"] ``

A segunda é gerar e guardar um inventário do que há em cada imagem — uma lista de materiais de software (SBOM). Quando um novo CVE crítico é anunciado, a pergunta imediata é "quais das minhas imagens contêm a biblioteca afetada?". Sem um inventário, essa resposta é uma caçada manual e demorada; com ele, é uma consulta. O SBOM transforma a resposta a vulnerabilidades de reativa e lenta em rápida e sistemática, o que importa muito quando o relógio corre contra uma falha divulgada.

Defesa em profundidade, não bala de prata

Nenhum desses dez itens sozinho torna um container seguro. O usuário não-root não salva se você embutiu um segredo na imagem. A imagem mínima não adianta se o container roda privilegiado. A força vem de empilhar as camadas: se uma falha, a próxima ainda segura o atacante. É o princípio da defesa em profundidade aplicado ao container.

Vale também situar o hardening no fluxo maior. Boa parte dessas práticas se aplica na construção da imagem (Dockerfile) e é verificável no pipeline de CI — o scan que quebra o build, o lint que recusa USER root, a política que barra o modo privilegiado. Assim, a segurança deixa de depender de alguém lembrar na hora do deploy e passa a ser garantida automaticamente, imagem após imagem.

O resumo prático: rode não-root, parta do mínimo, não carregue o que não usa, negue por padrão e devolva só o necessário, e nunca confie que "container já isola". Cada privilégio que você não concede é um caminho que o atacante não tem. Em segurança de container, o menor privilégio não é uma boa prática opcional — é a diferença entre uma falha contida e um host comprometido.