Segurança de Contêineres: Fortalecimento de Imagens e Proteção em Execução

Contêineres empacotam o código de um aplicativo e suas dependências em unidades isoladas que compartilham o kernel do OS hospedeiro, ao contrário das VMs, que incluem um OS convidado completo. Esse compartilhamento torna os contêineres leves e rápidos, mas introduz um modelo de segurança diferente: uma vulnerabilidade de escape de contêiner poderia permitir que um invasor saísse do contêiner e acessasse diretamente o kernel hospedeiro, afetando todos os outros contêineres. A segurança de contêineres concentra-se em três camadas: a imagem (o que é incorporado), o ambiente de execução (o que o contêiner pode fazer enquanto está em execução) e a plataforma de orquestração (como os contêineres são gerenciados).

Cada pacote instalado em uma imagem de contêiner é uma possível superfície de ataque. O princípio das imagens base mínimas significa começar pela base mais simples possível: Alpine Linux (5 MB, com poucos pacotes), imagens sem distribuição (imagens do Google que contêm apenas o ambiente de execução e o aplicativo, sem shell ou gerenciador de pacotes) ou scratch (completamente vazia, para binários compilados estaticamente). Um contêiner sem shell significa que um invasor que consiga executar código não poderá executar facilmente wget, curl ou outras ferramentas para ampliar o ataque — um princípio chamado defesa por exposição mínima.

Por padrão, os contêineres do Docker são executados como root (UID 0). Se um invasor explorar uma vulnerabilidade no aplicativo conteinerizado, ele obterá privilégios de root dentro do contêiner. Se o contêiner compartilhar um volume ou tiver montagens do hospedeiro, root dentro do contêiner pode equivaler a root no hospedeiro. A correção é simples: crie um usuário dedicado no Dockerfile e alterne para ele com a diretiva USER antes do CMD/ENTRYPOINT final. Muitas ferramentas de verificação de segurança de contêineres sinalizarão como descoberta qualquer imagem sem um usuário não-root.

Contêineres imutáveis são contêineres cujo sistema de arquivos não pode ser modificado durante a execução. Habilitar --read-only no Docker (ou readOnlyRootFilesystem: true no Kubernetes) impede que invasores gravem malware no disco, modifiquem arquivos de configuração ou instalem ferramentas dentro de um contêiner em execução. Aplicativos que realmente precisam gravar dados (registros, arquivos temporários) podem montar volumes tmpfs específicos para gravações efêmeras. Contêineres imutáveis aplicam o princípio de que o estado durante a execução deve vir apenas da imagem e da configuração, e não de modificações dentro do contêiner que contornem seu pipeline de segurança de CI/CD.

As ferramentas de verificação de imagens de contêineres analisam os pacotes instalados em uma imagem Docker comparando-os com bancos de dados de vulnerabilidades (NVD, CVE) e relatam CVEs conhecidas. Entre os principais verificadores estão Trivy (Aqua Security, rápido e gratuito), Grype (Anchore), Snyk Container e a verificação de imagens do AWS ECR. A verificação deve ser integrada ao pipeline de CI/CD para que qualquer imagem com CVEs críticas ou altas faça o pipeline falhar antes de ser enviada a um registro. Os verificadores também devem procurar segredos (chaves de API e senhas) incorporados acidentalmente às camadas da imagem.

Um erro comum e perigoso é incorporar segredos (chaves de API, senhas de banco de dados e certificados TLS) às imagens Docker — seja em variáveis de ambiente gravadas na imagem, seja em arquivos adicionados por meio de COPY. Esses segredos ficam visíveis para qualquer pessoa com acesso à imagem por meio de docker history ou pela extração das camadas da imagem. Mesmo que uma camada posterior exclua o arquivo, ele permanece no histórico da imagem. Os segredos devem ser injetados em tempo de execução por meio de variáveis de ambiente provenientes de um gerenciador de segredos, de segredos do Docker ou de Secrets do Kubernetes montados como volumes.

As ferramentas de segurança em tempo de execução monitoram o comportamento dos contêineres enquanto estão em execução e alertam ou bloqueiam atividades anômalas. O Falco (projeto da CNCF) conecta-se ao kernel do Linux usando eBPF ou módulos do kernel para interceptar chamadas de sistema e compará-las com regras. Por exemplo, uma regra pode gerar um alerta se um contêiner iniciar um Shell (execve('/bin/sh')), abrir uma conexão de rede em uma porta inesperada ou ler /etc/shadow. Esses indicadores comportamentais frequentemente sinalizam um ataque ativo, mesmo que nenhuma CVE conhecida tenha sido explorada. O Sysdig Secure e a Aqua Security fornecem plataformas comerciais de proteção em tempo de execução.

Por padrão, os contêineres Docker removem muitas capacidades do Linux, mas ainda mantêm mais do que a maioria dos aplicativos precisa. As capacidades dividem os privilégios de root em unidades distintas (por exemplo, CAP_NET_ADMIN e CAP_SYS_ADMIN). A prática recomendada é remover todas as capacidades e adicionar novamente apenas as necessárias com --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Os perfis do Seccomp (Modo de Computação Segura) definem quais chamadas de sistema um contêiner pode realizar — o Docker inclui um perfil padrão do Seccomp que bloqueia cerca de 44 chamadas de sistema perigosas. Perfis personalizados do Seccomp para aplicativos específicos podem restringir isso ainda mais, bloqueando todas as chamadas de sistema que o aplicativo nunca utiliza legitimamente.

Os registros de contêineres (Docker Hub, AWS ECR, Google Artifact Registry) armazenam e distribuem imagens. A proteção do registro envolve: habilitar a verificação de vulnerabilidades no envio, restringir o acesso de envio apenas às contas de serviço de CI/CD, habilitar a assinatura de imagens usando Sigstore/Cosign ou Docker Content Trust (Notary) para que os ambientes de execução extraiam apenas imagens assinadas criptograficamente de fontes confiáveis e configurar a imutabilidade das imagens para impedir que as tags sejam substituídas (eliminando ataques de mutação de tags, nos quais um invasor substitui uma tag :latest confiável por uma imagem maliciosa).

Invasores que obtêm execução de código dentro de um contêiner podem tentar realizar um escape de contêiner para alcançar o host. As técnicas comuns incluem: explorar contêineres privilegiados (--privileged fornece acesso quase irrestrito ao host), abusar de soquetes Docker expostos (/var/run/docker.sock montado em um contêiner fornece acesso total à API do Docker, inclusive para criar contêineres privilegiados) e explorar vulnerabilidades do kernel por meio de capacidades desprotegidas. Defesas: nunca use o modo privilegiado, a menos que seja absolutamente necessário; nunca monte o soquete do Docker em contêineres de aplicativos; mantenha o kernel do host corrigido; e use gVisor ou Kata Containers para cargas de trabalho que exigem forte isolamento.

O Center for Internet Security (CIS) Docker Benchmark fornece diretrizes detalhadas de configuração de segurança para hosts e contêineres Docker, abrangendo a configuração do daemon, a higiene das imagens, as configurações do tempo de execução dos contêineres e os controles de rede. Ferramentas como o Docker Bench for Security automatizam a verificação de conformidade com o referencial CIS, produzindo um relatório pontuado de itens aprovados ou reprovados. Executar esse referencial periodicamente e integrá-lo ao CI/CD garante que desvios na configuração de segurança sejam detectados rapidamente. Os candidatos à Security+ devem saber que os CIS Benchmarks são uma referência primária para o reforço de segurança de sistemas operacionais e plataformas no contexto do exame.

Teste sua compreensão dos conceitos da CompTIA Security+ (SY0-701) desta lição.

Nesta lição, você aprendeu que: imagens base mínimas e usuários não root reduzem a superfície de ataque e o nível de privilégio das cargas de trabalho conteinerizadas; ferramentas de proteção em tempo de execução, como o Falco, detectam padrões anômalos de chamadas de sistema que indicam ataques ativos dentro dos contêineres; e nunca se devem usar contêineres privilegiados nem montar o soquete do Docker em contêineres de aplicativos, pois essas configurações permitem o escape de contêineres. A seguir, exploraremos a segurança do Kubernetes, incluindo RBAC, políticas de rede e padrões de segurança de pods.