Segurança de Imagens Docker: Verificando Vulnerabilidades e Hardening

A segurança de imagens Docker é um pilar fundamental para a integridade de qualquer infraestrutura moderna. Muitas vezes, o foco inicial recai sobre a configuração do sistema operacional host ou as regras de firewall, negligenciando o fato de que as próprias imagens utilizadas pelos containers podem conter vulnerabilidades conhecidas (CVEs), dependências desatualizadas ou configurações inseguras por padrão. Este tutorial aborda como implementar um fluxo robusto de verificação e mitigação de riscos em suas imagens, integrando ferramentas de análise estática, políticas de registry privado e automação de atualização segura.

O objetivo principal não é apenas detectar falhas, mas estabelecer um ciclo de vida onde a segurança seja incorporada desde a construção da imagem até o runtime. Vamos explorar como utilizar scanners automatizados, configurar um registry privado com validação de integridade e garantir que as atualizações sejam aplicadas sem comprometer a disponibilidade dos serviços através de ferramentas como Watchtower e Traefik.

1. Preparação do Ambiente e Ferramentas Necessárias

Antes de iniciar a análise, é crucial ter um ambiente controlado. Recomendamos o uso de um arquivo docker-compose.yml que orquestre os serviços de monitoramento e segurança. Para este tutorial, assumimos que você já possui uma VPS com Docker e Docker Compose instalados.

A primeira etapa é criar a estrutura de diretórios para armazenar as imagens verificadas e os relatórios de vulnerabilidade. Isso garante que o histórico de análises seja preservado entre reinicializações do container de segurança.

1. Crie um diretório base para o projeto de segurança:

mkdir -p ~/docker-security/{scans,registry,data}
cd ~/docker-security

Dentro deste diretório, criaremos um docker-compose.yml que inclui um serviço de scanner (como Trivy ou Grype) e um registry privado básico para testar o fluxo de ingestão segura. Embora não configuremos um registry complexo aqui, a estrutura deve refletir a produção.

version: '3.8'
services:
  scanner:
    image: aquasec/trivy:latest
    volumes:
      - ./data:/root/.cache/trivy
      - ./scans:/output
      - /var/run/docker.sock:/var/run/docker.sock
    command: >
      image --security-checks vuln,secret
      --format json
      --output /output/report-$(date +%Y%m%d).json
      alpine:latest

Este compose inicializa o Trivy, que é uma scanner de vulnerabilidade popular e eficiente. Ele monta o socket do Docker para inspecionar as imagens locais e salva os relatórios no diretório scans.

2. Execução da Análise de Vulnerabilidades

Com a ferramenta configurada, o próximo passo é executar a varredura nas imagens que você planeja utilizar em produção. A segurança docker depende diretamente da frequência e rigor dessas análises.

1. Inicie o serviço de scanner:

docker-compose up -d

O comando acima iniciará a análise da imagem alpine:latest como exemplo. Após a conclusão, verifique os relatórios gerados:

ls -la ./scans/

Abrindo um arquivo de relatório JSON, você poderá identificar níveis de severidade (Critical, High, Medium). É fundamental estabelecer uma política: imagens com vulnerabilidades Critical ou High não devem ser promovidas para o ambiente de produção.

Se você estiver construindo suas próprias imagens, integre esse comando ao seu CI/CD. Por exemplo, no Dockerfile, você pode adicionar um stage que realiza a verificação antes do build final:

# Stage de build
FROM alpine:latest AS builder
RUN apk add --no-cache gcc musl-dev

# Stage de teste de segurança
FROM aquasec/trivy:latest
COPY --from=builder /app /app
RUN trivy image --exit-code 1 --severity HIGH,CRITICAL my-custom-app:latest

O flag --exit-code 1 garante que o build falhe se vulnerabilidades graves forem encontradas, impedindo que código inseguro seja embalado.

3. Configuração de Registry Privado com Validação

Para controlar rigorosamente quais imagens entram na sua infraestrutura, utilize um registry privado. Isso evita o uso de imagens públicas não verificadas. Vamos configurar um Minio ou Registry oficial simples para atuar como guardião.

No contexto de segurança de containers, o registry privado serve como uma camada adicional de filtragem. Apenas imagens que passaram pelo scanner descrito anteriormente devem ser pushadas neste repositório.

docker run -d \
  --name registry \
  -p 5000:5000 \
  -v $(pwd)/registry/data:/var/lib/registry \
  registry:2

Após configurar o registry, você deve garantir que as imagens sejam taggeadas corretamente antes do envio. Uma convenção comum é usar hashes de commit ou números de versão estáveis.

1. Taggee a imagem verificada:

docker tag alpine:latest localhost:5000/alpine-safe:v1.28

Ao enviar para o registry privado, você centraliza o controle de acesso. Certifique-se de configurar autenticação básica ou integrar com LDAP/Active Directory em ambientes corporativos para impedir pushes não autorizados.

4. Integração com Traefik e SSL Automático

Se seu registry ou painéis de monitoramento de segurança são expostos via internet, a segurança de transporte é obrigatória. O Traefik reverse proxy facilita essa configuração através de SSL automático usando Let's Encrypt.

No seu docker-compose.yml, defina o serviço do Traefik para gerenciar o roteamento e os certificados:

services:
  traefik:
    image: traefik:v2.10
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.httpchallenge=true"
      - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.myresolver.acme.email=admin@seudominio.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

Para expor o registry ou dashboard de segurança com SSL, adicione labels ao serviço correspondente:

  registry-ui:
    image: joxit/docker-registry-ui:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.registry.rule=Host(`registry.seudominio.com`)"
      - "traefik.http.routers.registry.entrypoints=websecure"
      - "traefik.http.routers.registry.tls.certresolver=myresolver"

O SSL automático garante que as comunicações entre o desenvolvedor e o registry, ou entre os serviços orquestrados, sejam criptografadas, protegendo contra ataques de intermediário (Man-in-the-Middle).

5. Gerenciamento de Atualizações com Watchtower

Após identificar e corrigir vulnerabilidades, você precisa aplicar as atualizações. O Watchtower é uma ferramenta essencial para automatizar a atualização de containers em execução. No entanto, em um contexto de segurança, o Watchtower deve ser configurado com cautela.

O uso indiscriminado do Watchtower pode trazer imagens não verificadas para produção. Portanto, configure-o para monitorar apenas tags específicas ou utilize ganchos (hooks) que disparam novas verificações antes da atualização.

services:
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_POLL_INTERVAL=3600
      - WATCHTOWER_INCLUDE_STOPPED=true

O ambiente WATCHTOWER_POLL_INTERVAL=3600 define que a verificação ocorre a cada hora. Em ambientes de alta segurança, aumente esse intervalo e execute atualizações manualmente após aprovação do time de DevOps.

Além disso, considere o uso de watchtower --run-once em scripts de CI para validar se há novas versões seguras antes de fazer deploy automático.

6. Isolamento via Redes Docker e Volumes Persistentes

A segurança também depende do isolamento. Nunca exponha serviços internos de scanner ou registry na rede pública. Utilize redes docker customizadas para criar segmentos lógicos.

1. Crie uma rede isolada para os componentes de infraestrutura:

docker network create secure-net

No seu compose, associe os serviços críticos a esta rede e remova as portas expostas ao host (0.0.0.0), permitindo comunicação apenas entre containers:

  registry:
    networks:
      - secure-net
    # Não exponha porta 5000 aqui se for usar Traefik ou acesso interno

Isso impede que um container comprometido na rede externa acesse diretamente o banco de dados do registry ou as credenciais armazenadas nos volumes persistentes.

Quanto aos volumes persistentes, certifique-se de que os dados sensíveis, como certificados SSL e chaves de API, estejam em volumes com permissões restritas no sistema de arquivos host:

chmod 700 ./letsencrypt
chown -R root:root ./letsencrypt

Essa prática reduz a superfície de ataque caso um container ganhe privilégios de leitura.

7. Automação e Monitoramento Contínuo

A verificação de vulnerabilidades não é um evento único, mas um processo contínuo. Novas CVEs são descobertas diariamente. Integre o scanner ao seu pipeline de entrega contínua.

Crie um script shell simples que verifica a última data do relatório e executa uma nova varredura se necessário:

#!/bin/bash
REPORT_DIR="./scans"
LATEST_REPORT=$(ls -t $REPORT_DIR/*.json | head -n 1)
HOURS_SINCE_CHECK=$(( ( $(date +%s) - $(stat -c %Y "$LATEST_REPORT") ) / 3600 ))

if [ $HOURS_SINCE_CHECK -gt 24 ]; then
    echo "Executando varredura de segurança..."
    docker-compose exec scanner trivy image --exit-code 1 --severity HIGH,CRITICAL my-app:latest
    echo "Varredura concluída."
else
    echo "Varredura recente. Pulando execução."
fi

Este script pode ser agendado via Crontab no host ou integrado como um job no Jenkins/GitLab CI.

Conclusão e Melhores Práticas

A segurança de imagens Docker exige uma abordagem em camadas. Comece com a construção limpa das imagens, passe pela verificação automatizada com ferramentas como Trivy, restrinja o acesso via registry privado e redes isoladas, e mantenha os sistemas atualizados com automação cuidadosa.

Lembre-se de que:

• Nunca use root dentro do container: Defina usuários não privilegiados no Dockerfile.
• Mantenha as imagens pequenas: Menos pacotes significam menor superfície de ataque.
• Monitore logs: Utilize ferramentas centralizadas para detectar comportamentos anômalos nos containers.
• Atualize o Docker Engine e Compose: Mantenha a orquestração segura.

Ao seguir estes passos, você transforma a segurança de containers de um obstáculo reativo em uma vantagem competitiva proativa. A combinação de traefik reverse proxy para roteamento seguro, watchtower para manutenção ágil e volumes persistentes protegidos cria uma base sólida para aplicações críticas em VPS.

Para ir além, considere implementar políticas de Pod Security Standards se migrar para Kubernetes no futuro, ou utilizar ferramentas de runtime security como Falco para detecção de intrusão em tempo real. A segurança é um caminho, não um destino.