Por que contêineres não deveriam executar como root por padrão?

Executar contêineres como root é uma das configurações incorretas mais comuns — e mais perigosas — em ambientes de produção. Aumenta silenciosamente a superfície de ataque de cada workload, e a maioria dos times não percebe até um incidente forçar a questão.

O que "Executar como root" realmente significa

Por padrão, muitas imagens de contêiner (especialmente as mínimas ou legadas) executam seu processo principal como UID 0 dentro do contêiner. Como contêineres compartilham o kernel do host com outros contêineres e o próprio host, root dentro de um contêiner não é a mesma coisa que root em uma máquina virtual completamente isolada — mas ainda é muito mais poderoso do que deveria ser. Se um atacante alcançar execução de código dentro de um contêiner executado como root, ele herda:

• Acesso completo de leitura/escrita a qualquer arquivo montado no contêiner, independentemente das permissões pretendidas
• A capacidade de instalar pacotes, modificar binários ou alterar o estado da aplicação
• Um caminho muito mais fácil para container breakout se uma vulnerabilidade do kernel ou runtime for explorável
• Alavancagem elevada quando combinada com volumes mal configurados, como um Docker socket montado ou um caminho do filesystem do host

Mesmo sem um exploit de kernel, o acesso root dentro do contêiner aumenta dramaticamente o raio de explosão de qualquer vulnerabilidade no nível da aplicação (SSRF, bugs de desserialização, escrita arbitrária de arquivo, etc.).

Por que isso importa mais em ambientes orquestrados

Em clusters Kubernetes, um contêiner root combinado com capacidades Linux excessivas ou um security context permissivo pode permitir que um atacante:

• Modifique /proc ou /sys de formas que afetem o host
• Escalpe privilégios se hostPID, hostNetwork ou hostIPC estiverem ativados
• Abuse um token de service account montado para pivotar lateralmente pelo cluster
• Escape para o nó se privileged: true estiver definido ou capacidades perigosas como SYS_ADMIN forem concedidas

O próprio usuário root nem sempre é a vulnerabilidade — é a combinação de root mais capacidades de kernel excessivamente generosas, montagens de host ou compartilhamento de namespaces que transforma um comprometimento contido em um comprometimento de cluster inteiro.

Passos práticos de hardening

1. Defina um usuário não-root na imagem

Defina explicitamente um usuário não-root no seu Dockerfile em vez de confiar em padrões:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Aplique no nível do orquestrador

Não confie apenas na imagem — aplique a política em tempo de execução. Em Kubernetes, use um securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true faz com que o pod falhe na admissão se a imagem tentar executar como UID 0, dando a você uma garantia difícil em vez de uma convenção best-effort.

3. Elimine capacidades desnecessárias

A maioria das aplicações não precisa de nenhuma das capacidades Linux padrão concedidas a contêineres. Elimine tudo e adicione novamente apenas o que for estritamente necessário (casos raros como vinculação a portas baixas podem precisar de NET_BIND_SERVICE).

4. Evite modo privilegiado e compartilhamento de namespace do host

privileged: true, hostNetwork: true e hostPID: true devem ser reservados para workloads de infraestrutura muito específicos (como certos agentes de CNI ou monitoramento) — nunca para contêineres de aplicação geral.

5. Escaneie e aplique com ferramentas de política

Use controladores de admissão ou motores de política (por exemplo, Kyverno, OPA/Gatekeeper) para rejeitar automaticamente deployments que violem essas regras, em vez de confiar em revisão manual de código. Combine isso com scanning de imagem em CI para detectar imagens com usuário root antes de chegarem a um cluster.

Uma defesa em camadas, não perfeita

Executar como não-root não elimina risco completamente — container escapes no nível de kernel existem independentemente do usuário dentro do contêiner — mas remove uma classe enorme de técnicas de escalação de privilégios e movimento lateral de baixo esforço. Combinado com filesystems somente leitura, capacidades eliminadas e políticas de rede restritivas, forma uma das camadas mais baratas e efetivas em uma estratégia de defesa em profundidade para segurança de contêineres.

Quer aprofundar em hardening de workloads cloud-native? Explore segmentos relacionados do Korra Studio sobre Cloud security e hardening de pipeline DevOps para construir o resto da sua estratégia de defesa em profundidade.