Sua equipe de infraestrutura migrou para containers achando que resolveria o problema de "funciona na minha máquina". Resolveu — e criou uma superfície de ataque nova, que a maioria dos pentests tradicionais nem olha. Scanner de rede não enxerga um RBAC mal configurado dentro do cluster. Teste de aplicação web não encontra um Secret exposto em variável de ambiente de um pod. É uma camada inteira de infraestrutura rodando sem o mesmo escrutínio que servidor físico ou nuvem já recebem.
O Que Muda Quando a Infraestrutura Vira Container
Em um servidor tradicional, o perímetro é claro: firewall, rede, sistema operacional. Em Kubernetes (o orquestrador que organiza containers em um cluster), o perímetro vira uma malha de componentes — API server, nós, pods, redes internas, imagens, registries — cada um com sua própria superfície de ataque. Um único container comprometido pode virar porta de entrada para o cluster inteiro se a segmentação interna não existir.
Isso importa porque a decisão de usar containers normalmente não passa pela segurança. Passa pelo time de desenvolvimento, que quer entregar mais rápido. O resultado comum: cluster em produção, rodando há meses, sem nunca ter sido avaliado por alguém de fora do time que o configurou.
Os Riscos Mais Comuns em Ambientes com Containers
Container privilegiado: um container rodando em modo privileged tem acesso equivalente ao root do host. Se o atacante compromete a aplicação dentro dele, sai direto para o servidor que hospeda o cluster.
Imagens desatualizadas: imagens de container puxadas de registries públicos (Docker Hub, por exemplo) carregam as vulnerabilidades da versão em que foram publicadas. Sem um processo de scan e atualização, o time está rodando em produção um pacote com CVE (identificador público de uma vulnerabilidade conhecida) já documentada e explorável.
RBAC mal configurado: o RBAC (controle de acesso baseado em papéis) do Kubernetes define quem pode criar, ler ou apagar o quê dentro do cluster. Uma permissão ampla demais dada a um service account de aplicação é, na prática, uma conta de administrador exposta dentro de um pod.
Secrets expostos: senhas, tokens e chaves de API armazenados como variável de ambiente ou em ConfigMap sem criptografia aparecem inteiros para qualquer processo com acesso de leitura ao pod — inclusive um processo malicioso rodando depois de uma exploração inicial.
API server exposta à internet: o componente que controla todo o cluster, quando acessível publicamente sem autenticação forte, é o alvo número um. Scanners automatizados varrem a internet só procurando API servers abertos.
Ausência de network policies: sem regras explícitas de rede interna, qualquer pod comprometido consegue conversar livremente com qualquer outro pod do cluster. É o que transforma uma falha pontual em movimento lateral completo.
Como Isso Costuma Ser Explorado na Prática
- O atacante encontra uma vulnerabilidade na aplicação exposta (ex: injeção, upload de arquivo, dependência desatualizada) e ganha execução de código dentro de um container.
- Sem network policy, ele varre a rede interna do cluster e encontra outros serviços — bancos de dados, APIs internas, painéis administrativos — que nunca foram pensados para ficar acessíveis de dentro.
- Com um service account de permissão ampla, ele lista Secrets do namespace e coleta credenciais de outros sistemas, incluindo, às vezes, credenciais de nuvem (AWS, Azure, GCP) usadas pelo próprio cluster.
- Se o container está em modo privilegiado ou há uma falha de isolamento no runtime, o passo final é sair do container e comprometer o nó que hospeda o cluster inteiro.
Como Testar Isso na Prática
Um pentest de ambiente com containers precisa ir além da aplicação:
- Revisão de configuração do cluster: manifestos YAML, RBAC, network policies e configuração do API server, comparados contra o benchmark CIS para Kubernetes.
- Scan de imagens: identificação de CVEs conhecidas nas imagens em uso, incluindo camadas base herdadas de terceiros.
- Teste de escape de container: tentativa controlada de sair do isolamento do container e alcançar o host, nas condições reais do ambiente do cliente.
- Teste de movimento lateral: a partir de um pod comprometido, mapear o quanto é possível alcançar outros serviços do cluster sem autorização adicional.
- Revisão de pipeline: checagem de como as imagens chegam ao registry e ao cluster — se há assinatura, scan automático e quem pode publicar uma imagem nova em produção.
Isso é parte do que a LDL Security cobre dentro de um pentest de infraestrutura: testamos servidores, redes e, cada vez mais, clusters Kubernetes e ambientes containerizados com a mesma metodologia — reconhecimento, exploração controlada e relatório com evidência, não só uma lista de CVEs copiada de um scanner. Veja mais em pentest de infraestrutura.
Perguntas Frequentes
Um scanner de vulnerabilidades já resolve isso?
Resolve parte. Um scanner encontra CVEs em imagens, mas não testa se o RBAC está permissivo demais, se o isolamento do container realmente segura uma tentativa de escape, ou se dá para pular de um pod para outro sem permissão. Isso exige teste manual, não só varredura automatizada.
Containers tornam a infraestrutura mais insegura que servidores tradicionais?
Não necessariamente — tornam diferente. Um cluster bem configurado, com RBAC restrito, network policies ativas e scan de imagem no pipeline, pode ser mais seguro que um servidor monolítico mal gerido. O problema é que a maioria dos ambientes em produção não tem essa configuração validada por ninguém de fora do time que a criou.
Isso tem relação com ataques de cadeia de suprimentos de software?
Sim, diretamente. Uma imagem de container comprometida ou uma dependência maliciosa publicada em um registry é uma forma de supply chain attack. Detalhamos esse tipo de risco em supply chain attacks.
Leia também
Pentest de Infraestrutura: Como Proteger Servidores e Redes Corporativas
Supply Chain Attacks: O Elo Fraco da Sua Cadeia de Software
Fale com a LDL Security sobre pentest de infraestrutura e Kubernetes →