PENTESTY · ANÁLISE EDITORIAL · · 4 min de leitura
Carbonato: a permissão para criar containers alcança o host?
Publicar uma imagem e administrar sua execução são poderes diferentes. A revisão precisa acompanhar a identidade que cria o workload e as capacidades que ele recebe.
Por Pentesty
O recorte confirmado da pesquisa
Em 22 de setembro de 2026, a ThreatDown descreveu o Carbonato como uma botnet que compromete daemons Docker acessíveis sem autenticação e usa containers privilegiados para alcançar o host. O estudo também descreve mecanismos de persistência e propagação. O caminho documentado é Docker; a discussão sobre Kubernetes abaixo é uma comparação técnica, baseada na documentação do projeto, e não uma atribuição da mesma campanha a clusters.
Localize quem administra a execução
Escolha uma aplicação e identifique como sua carga é criada. Registre a pessoa ou automação que solicita a execução, a credencial usada, o endpoint administrativo e o responsável pela plataforma. Inclua ferramentas de desenvolvimento e integrações de entrega que alcançam esse caminho, mesmo quando pertencem a outra equipe.
Depois separe a publicação da imagem da autoridade sobre sua execução. A análise do GhostPat no Docker Hub trata da identidade que publica artefatos. Aqui, a pergunta é quais configurações a identidade de execução consegue solicitar e quem aceita esse alcance.
Compare criar um workload com seus efeitos
A documentação de RBAC do Kubernetes explica que criar workloads pode permitir acesso a recursos utilizados por eles, como segredos e identidades de serviço. Por isso, a revisão deve considerar a configuração efetivamente admitida, além do nome da função atribuída. Docker e Kubernetes têm modelos distintos; confirme quais controles existem no ambiente concreto.
Monte uma relação entre a necessidade da aplicação e os recursos solicitados: volumes, identidade, rede e permissões. Peça uma justificativa para cada capacidade adicional. Quando o controle esperado não existe naquela arquitetura, registre a lacuna e a decisão necessária, sem tratar uma convenção de equipe como uma barreira técnica demonstrada.
Use um teste pequeno para demonstrar o limite
Em um laboratório autorizado, prepare uma aplicação inofensiva, uma identidade de teste e dados sintéticos. Defina uma configuração permitida e outra que deve ser recusada. Não é necessário instalar a botnet, procurar servidores públicos ou acessar arquivos reais do host para avaliar a decisão de autorização.
Observe a solicitação, a decisão da plataforma e o estado resultante. Uma configuração recusada antes de iniciar e uma carga que inicia com alcance excessivo são resultados diferentes. Combine limite de recursos, duração, critérios de parada e limpeza para que o exercício tenha um resultado verificável.
- Identidade: quem solicita a criação e em qual contexto.
- Configuração: quais capacidades foram pedidas e aprovadas.
- Efeito: o que a carga de teste conseguiu alcançar.
- Encerramento: quais recursos e permissões foram removidos.
Inclua segredos e automações no mesmo mapa
Confirme quais credenciais ficam disponíveis durante a execução e qual serviço cada uma permite acessar. Use marcadores sintéticos para verificar a entrega sem copiar segredos de produção para o relatório. Uma configuração aprovada pode continuar inadequada se expõe uma credencial desnecessária para a tarefa.
As fronteiras de confiança no GitHub Actions ajudam a conectar a origem da automação ao ambiente que ela administra. A permissão deve ter finalidade e responsável identificáveis. Verifique como ela termina quando a integração muda, sem presumir que excluir um arquivo invalida uma credencial já distribuída.
Perguntas frequentes
A pesquisa confirma ataques Carbonato a Kubernetes?
O estudo citado documenta o caminho por daemons Docker. A comparação com Kubernetes usa documentação técnica do projeto e não confirma a mesma campanha em clusters.
Autenticar a API demonstra privilégio mínimo?
A autenticação identifica o solicitante. A avaliação também precisa verificar quais configurações e recursos essa identidade consegue usar, segundo os controles efetivamente disponíveis.
O teste exige um container com acesso real ao host?
A proposta usa laboratório, dados sintéticos e critérios de recusa. Qualquer validação adicional precisa de autorização específica e compatibilidade com a operação.
Qual evidência deve acompanhar a correção?
Identidade, solicitação, decisão observada, estado resultante e limpeza, com responsáveis. Inclua a execução permitida e a configuração que foi recusada dentro da amostra.
Fontes e referências
- ThreatDown: pesquisa Carbonato, 22 de setembro de 2026
- Docker: proteção do socket do daemon
- Kubernetes: boas práticas de RBAC
- Cyber Security Brazil: referência editorial da notícia
Análise original da Pentesty, publicada em 16 de outubro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.