Segurança no Docker: Porque Correr Containers como Root é um Perigo e Como Usar Rootless e Distroless

O Mito da Virtualização no Docker e o Perigo do Root

O erro mais comum entre programadores e equipas técnicas é acreditarem que um container do Docker funciona como uma máquina virtual completamente isolada. Os containers não são máquinas virtuais; são processos normais de Linux isolados por cgroups, namespaces e filtros seccomp. O detalhe fundamental é que todos os containers partilham o mesmo kernel do teu servidor físico.

Por padrão, quando instalas o Docker num servidor, o serviço dockerd corre com permissões de root. Se no teu Dockerfile não definires a instrução USER, a tua aplicação web corre como utilizador UID 0. Se a tua aplicação sofrer uma vulnerabilidade de execução remota de código (RCE) e o atacante explorar uma falha no kernel do Linux, ele salta para fora do container e assume o controlo absoluto do teu servidor como root.

ESCAPE NO DOCKER NORMAL VS. PROTEÇÃO ROOTLESS

• CONFIGURAÇÃO PADRÃO COM ROOT (PERIGO CRÍTICO): [ Container: Processo UID 0 (root) ] → Explora Falha no Kernel
• Controlo Total do Teu Servidor: O Atacante Torna-se Root no Host
• DOCKER ROOTLESS COM NAMESPACES DE UTILIZADOR (BLINDADO): [ Container: Processo UID 0 (virtual) ] → Tenta Escapar para o Host
• Host: Mapeado para Utilizador Comum UID 10005: (O Ataque Falha Completamente)

Na Webxtek, encaramos a segurança de infraestrutura como uma responsabilidade por camadas. Através da nossa consultoria técnica, ajudamos as equipas a eliminar processos desnecessários com permissões de administrador, garantindo que mesmo no pior cenário de invasão a tua máquina permanece intocável.

Como Instalar e Configurar o Docker Rootless em Produção

O modo Rootless permite que o daemon do Docker e todos os teus containers corram inteiramente sob a conta de um utilizador comum sem privilégios administrativos no Debian. Mesmo que um invasor quebre o isolamento do container, encontra-se preso num utilizador local com acesso negado a ficheiros críticos do sistema.

Para ativares o Docker Rootless no teu servidor de produção:

# Instala as dependências de namespaces de utilizador
apt-get install -y dbus-user-session uidmap

# Muda para o utilizador que vai correr as aplicações
su - utilizadorapp

# Executa o assistente de instalação do Docker sem root
dockerd-rootless-setuptool.sh install

# Ativa o serviço ao nível do utilizador no systemd
systemctl --user enable --now docker.service

# Configura o socket do Docker no ambiente do utilizador
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

ESTRUTURA DE EXECUÇÃO DO DOCKER ROOTLESS

• Sistema Operativo Anfitrião (Kernel Linux)
• Utilizador Sem Privilégios: utilizadorapp (UID: 1000)
• rootlesskit + slirp4netns (Pilha de Rede Não Privilegiada)
• dockerd (Daemon Rootless a Correr na Namespace do Utilizador)
• O Teu Container: Mapeia o UID 0 Virtual para o UID 100000 do Host

Neste modelo, como o teu utilizador não pode abrir portas baixas (< 1024) diretamente, colocas um reverse-proxy seguro à frente ou utilizas túneis encriptados para gerir o tráfego de entrada.

Imagens Distroless: Eliminar Shells e Utilitários Inúteis

Muitos projetos continuam a usar imagens pesadas como node:22-bullseye ou python:3.12-alpine para colocar código em produção. Estas imagens incluem sistemas operativos completos com interpretadores de comandos (/bin/sh ou /bin/bash), utilitários como curl e wget, e centenas de ficheiros de que a tua aplicação em execução nunca vai precisar.

Quando um atacante explora uma falha de injeção no teu código, a primeira coisa que faz é tentar abrir uma consola bash ou usar o curl para descarregar um cavalo de Troia. Se essas ferramentas não existirem no disco, o ataque fica completamente paralisado.

As imagens Distroless da Google contêm apenas a tua aplicação compilada e os ficheiros mínimos do runtime. Não contêm gestores de pacotes nem nenhum interpretador de comandos:

# Build multi-etapas para aplicação Node.js
# ETAPA 1: Compilação e Dependências
FROM node:22-bookworm-slim AS construtor
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build

# ETAPA 2: Runtime Distroless Mínimo
FROM gcr.io/distroless/nodejs22-debian12:nonroot
WORKDIR /app
COPY --from=construtor --chown=nonroot:nonroot /app/dist ./dist
COPY --from=construtor --chown=nonroot:nonroot /app/node_modules ./node_modules
COPY --from=construtor --chown=nonroot:nonroot /app/package.json ./

# Corre como utilizador nonroot (UID 65532) sem qualquer shell
USER nonroot
EXPOSE 3000
CMD ["dist/server.js"]

IMAGEM PADRÃO VS. SUPERFÍCIE MÍNIMA DISTROLESS

• IMAGEM UBUNTU / DEBIAN PADRÃO: [ O Teu Código ] + [ bash, sh, curl, wget, apt, python, centenas de binários ]
• Superfície de Ataque: Enorme (O invasor tem ferramentas para explorar o sistema)
• IMAGEM GOOGLE DISTROLESS NONROOT: [ O Teu Código ] + [ Apenas o Motor Node.js ]
• Superfície de Ataque: Nula (Sem shell, sem utilitários de rede, disco só de leitura)

Esta redução agressiva de dependências reflete a nossa visão contra o anti-over-engineering: menos código desnecessário significa menos vulnerabilidades em produção.

Auditoria de Vulnerabilidades com Trivy no Teu CI/CD

Novas falhas de segurança (CVEs) são descobertas diariamente em pacotes de código aberto e bibliotecas externas. Em vez de descobrires que estás vulnerável através de um incidente em produção, deves integrar o Trivy no teu fluxo automático de publicação.

O Trivy analisa as tuas imagens à procura de falhas no sistema operativo e nas dependências de código:

# Analisa a imagem e bloqueia se encontrar falhas Críticas ou Altas
trivy image \
  --severity CRITICAL,HIGH \
  --ignore-unfixed \
  --exit-code 1 \
  minha-aplicacao-prod:latest

PORTÃO DE SEGURANÇA COM SCANNER TRIVY

• Envias Código para o Git
• Criação da Imagem Distroless em CI/CD
• Execução do Trivy Scanner
• Encontrou Falha Crítica / Alta?
• Sim
• CANCELA O BUILD E IMPEDE O DEPLOY
• Não → [ Publica Imagem no Servidor em Produção ]

Ao implementares as boas práticas recomendadas pela OWASP e associares esta esteira rigorosa às nossas soluções de alojamento gerido, garantes que as tuas aplicações operam isoladas, blindadas e totalmente livres de vulnerabilidades conhecidas.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e cibersegurança. Quando alinhas a tua estrutura através de consultoria técnica antes de construir e alojamento gerido para websites e aplicações, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.