💻 computer science

Runtime Detection of Attacks and Misconfigurations in Cloud-Native Kubernetes Environments Using eBPF Network Telemetry

Este artigo demonstra que a telemetria de rede Hubble/eBPF, quando combinada com rótulos de verdade fundamental cuidadosamente construídos, pode detectar eficazmente ataques em tempo de execução e más configurações em ambientes Kubernetes, revelando que os atributos de identidade do lado do destino são os indicadores mais fortes de ameaças, apesar de um compromisso entre a alta precisão dos detectores baseados em regras e o maior recall dos classificadores Random Forest.

Autores originais: Andrew Oppong-Asante, Bernard Kyiewu, Clinton Amponsah, Linda Bessa-Simons, Caleb Boakye Yiadom

Publicado 2026-06-25

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Andrew Oppong-Asante, Bernard Kyiewu, Clinton Amponsah, Linda Bessa-Simons, Caleb Boakye Yiadom

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um cluster Kubernetes como um edifício de escritórios enorme e movimentado onde milhares de pequenos trabalhadores temporários (chamados de containers) vivem e trabalham. Esses trabalhadores são organizados em diferentes departamentos (chamados de namespaces). Em um edifício seguro, existem regras estritas: a equipe de contabilidade não pode vagar pela sala do servidor, e os estagiários não podem acessar o escritório do CEO.

No entanto, às vezes, os gerentes do edifício cometem erros. Eles podem deixar portas destrancadas, dar a todos a chave mestra ou permitir que os trabalhadores usem armaduras de "super-traje" que lhes permitem quebrar paredes. Esses erros são desconfigurações.

Este artigo é sobre a construção de um sistema de câmeras de segurança superpoderoso para pegar maus atores no momento em que tentam explorar esses erros, sem atrasar o funcionamento do edifício.

O Problema: Portas Invisíveis e Chaves Mestras

Os pesquisadores começaram criando intencionalmente três erros específicos em seu edifício de escritórios de teste:

Sem Guardas de Segurança (Políticas de Rede Ausentes): Eles removeram as regras que impedem os trabalhadores de caminhar entre os departamentos. Agora, qualquer um poderia caminhar para qualquer lugar.
Muitas Chaves Mestras (RBAC Excessivo): Eles deram a um trabalhador de baixo nível uma chave que abria todas as portas do edifício, incluindo o cofre secreto.
Super-Trajes (Containers Privilegiados): Eles deixaram um trabalhador usar um traje que o permitia ver e tocar em tudo, até mesmo na fundação e na fiação elétrica do edifício.

Uma vez que esses erros foram colocados no lugar, eles enviaram uma "red team" (um grupo de hackers éticos) para tentar invadir, roubar dados ou saltar de um departamento para outro.

A Solução: A Super-Câmera "eBPF"

Para capturar esses intrusos, os pesquisadores não usaram uma câmera de segurança padrão. Eles usaram algo chamado eBPF (extended Berkeley Packet Filter), que descrevem como um sensor superavançado e de alta velocidade incorporado diretamente no encanamento e na fiação do edifício.

Este sensor, pareado com uma ferramenta chamada Hubble, não apenas tira fotos; ele registra cada única gota de água (dados) fluindo pelos canos. Ele sabe exatamente:

Quem enviou a gota (Source Pod).
Quem recebeu a gota (Destination Pod).
Por qual cano ela passou (Namespace).
Que tipo de gota era (Porta/Protocolo).

Os pesquisadores coletaram mais de 3,8 milhões desses "registros de fluxo" (gotas de dados).

O Grande Desafio: Separar o Ruído

Aqui está a parte complicada: a câmera registrou tudo. Na maior parte do tempo, o edifício estava apenas realizando um trabalho normal (tráfego benigno). Os ataques reais eram como encontrar algumas agulhas em um palheiro de 3 milhões de pedaços de feno.

Além disso, a câmera tinha uma peculiaridade estranha. Às vezes, ela via a gota de água saindo da torneira (TO_STACK), às vezes quando ela atingia o cano (TO_ENDPOINT) e às vezes enquanto ela viajava pela linha principal (TO_OVERLAY).

O Problema: Quando a câmera via a gota no estágio da "torneira", ela frequentemente não conseguia ver para onde ela estava indo. Era como ver uma carta sair de uma caixa de correio, mas não saber o endereço no envelope.
A Correção: Os pesquisadores tiveram que passar por um rigoroso processo de limpeza de quatro etapas para descartar os registros borrados e incompletos e manter apenas aqueles onde podiam ver claramente o destino. Isso transformou seus 3,8 milhões de registros bagunçados em um conjunto de dados limpo de 3,18 milhões de registros, com apenas 456 registros de "ataque" confirmados.

Os Detetives: Regras vs. IA

Os pesquisadores testaram duas maneiras diferentes de identificar os bandidos nos dados limpos:

O Detetive Baseado em Regras: Este detetive segue uma lista de verificação estrita. "Se um trabalhador do departamento 'Atacante' tentar falar com o departamento 'Banco de Dados' na porta 5432, toque o alarme!"
- Resultado: Este detetive foi muito preciso. Quando tocava o alarme, geralmente estava certo. No entanto, ele perdeu alguns ataques sorrateiros que não se encaixavam em sua lista de verificação exata.
O Detetive de Floresta Aleatória (IA): Este detetive é como um estudante que estudou milhares de exemplos de comportamentos normais e ruins. Ele olha para o quadro geral e adivinha: "Isso parece 80% um ataque."
- Resultado: Este detetive pegou mais dos bandidos (maior recall), mas também tocou o alarme algumas vezes quando era apenas um trabalhador normal fazendo algo ligeiramente incomum.

A Grande Descoberta: Para Quem Você Está Falando Importa Mais

A descoberta mais surpreendente foi sobre com quem os bandidos estavam tentando falar.

Os pesquisadores descobriram que as pistas mais importantes não eram sobre quem enviou a mensagem, mas sim quem a recebeu.

A Metáfora: Não importa se uma pessoa de aparência normal (Origem) envia uma carta. O que importa é que ela está tentando entregá-la ao Cofre do Banco (Destino).
A Proporção: As pistas de "Destino" foram 2,8 vezes mais importantes do que as pistas de "Origem". Se um trabalhador tenta falar com o banco de dados ou o servidor de API, isso é um enorme sinal de alerta, independentemente de quem ele seja.

A Conclusão

O artigo conclui que o uso desses sensores de alta velocidade (eBPF/Hubble) funciona muito bem para capturar ataques em tempo real, mas apenas se você for muito cuidadoso sobre como rotula os dados.

Se você não filtrar os registros borrados (onde o destino é desconhecido), você não consegue distinguir entre um trabalhador normal e um hacker. Mas se você fizer a limpeza corretamente, pode construir um sistema que detecta intrusos no momento em que tentam saltar entre departamentos ou acessar o cofre.

Em resumo: Você pode pegar os bandidos em um edifício de escritórios na nuvem, mas precisa de uma supercâmera que saiba exatamente para onde a água está indo, e precisa ensinar seus guardas de segurança que para onde a mensagem está indo é mais importante do que quem a enviou.

Resumo Técnico: Detecção de Ataques e Misconfigurações em Tempo de Execução em Ambientes Kubernetes Cloud-Native Usando Telemetria de Rede eBPF

Declaração do Problema

O Kubernetes tornou-se o padrão de fato para cargas de trabalho cloud-native, mas sua flexibilidade introduz uma superfície de configuração complexa, propensa a riscos de segurança. Misconfigurações (erros de configuração), como a ausência de NetworkPolicies, permissões excessivas de Controle de Acesso Baseado em Funções (RBAC) e execução de containers privilegiados, criam caminhos exploráveis para movimentação lateral, acesso não autorizado a serviços e escalonamento de privilégios. Embora a análise estática e o endurecimento (hardening) pré-implantação existam, eles frequentemente falham em capturar padrões de comunicação inseguros que se manifestam apenas em tempo de execução. Além disso, as abordagens existentes de detecção em tempo de execução dependem frequentemente de telemetria de chamadas de sistema ou conjuntos de dados de rede genéricos que carecem de contexto específico do Kubernetes. Permanece uma lacuna metodológica significativa no uso da telemetria de rede Hubble/eBPF para segurança: a arquitetura de múltiplos pontos de observação do Cilium (TO_STACK, TO_ENDPOINT, TO_OVERLAY) cria desafios para a construção de um ground truth (verdade fundamental) confiável ao nível de fluxo, pois a completude dos metadados varia entre esses pontos.

Metodologia

O estudo emprega uma abordagem experimental reprodutível para enfrentar esses desafios através das seguintes etapas:

Ambiente Experimental: Foi estabelecido um cluster kind (Kubernetes-in-Docker) de quatro nós rodando Kubernetes v1.35.0. O Cilium v1.16.6 foi implantado como a Interface de Rede de Contêiner (CNI) com o Hubble habilitado para observabilidade por fluxo.
Design de Workload e Namespace: O ambiente hospedou uma aplicação de microsserviços de múltiplas camadas distribuída em cinco namespaces: frontend, backend, database, attacker e monitoring.
Injeção de Misconfigurações: Três classes específicas de misconfiguração foram introduzidas para permitir ataques:
- M1 (Ausência de Network Policy): Nenhuma NetworkPolicy implantada, permitindo rede de pods plana (flat networking).
- M2 (RBAC Excessivo): Uma conta de serviço no namespace do atacante recebeu privilégios de cluster-admin.
- M3 (Runtime Privilegiado): Um pod foi configurado com privileged: true, montagens de hostPath e capacidades elevadas do Linux.
Cenários de Ataque: Quatro cenários de ataque foram executados contra o cluster misconfigurado:
- Ataque A: Movimentação lateral via varredura de rede interna (nmap).
- Ataque B: Tentativas repetidas de acesso não autorizado ao banco de dados.
- Ataque C: Acesso ao sistema de arquivos do host via containers privilegiados.
- Ataque D: Abuso de RBAC para enumeração de segredos em todo o cluster.
Coleta de Telemetria e Resolução de Ground-Truth: O Hubble capturou registros JSON por fluxo. Para abordar o desafio do ground-truth causado pela variabilidade da completude de metadados nos pontos de observação, um processo de resolução de ground-truth de quatro versões foi aplicado:
- v1: Rotulagem inicial ao nível de arquivo (superestimou ataques).
- v2: Remoção do tráfego do pod atacante (superfiltragem, resultando em zero ataques).
- v3: Aplicação de filtragem de ponto de observação e lógica de namespace de origem ao nível de fluxo.
- v4 (Final): Exclusão da comunicação do pod atacante com namespaces de infraestrutura (ex: kube-system), resultando em um conjunto limpo de fluxos de origem de ataque.
Framework de Detecção: Dois detectores foram avaliados:
- Detector Baseado em Regras Comportamentais: Definiu regras para acesso ao banco de dados entre namespaces, movimentação lateral e varredura de portas sensíveis.
- Classificador Random Forest: Treinado em características derivadas do Hubble (identidades, portas, pontos de observação, flags TCP) com pesos de classe balanceados.
Avaliação: Os modelos foram avaliados usando validação cruzada de janela temporal de cinco dobras (five-fold time-windowed cross-validation), priorizando a análise de Precisão-Recall e a Área Sob a Curva de Precisão-Recall (AUPRC) devido ao severo desequilíbrio de classes.

Principais Contribuições

Testbed Reprodutível: Desenvolvimento de um testbed Kubernetes de quatro nós instrumentado com Cilium/Hubble, hospedando uma aplicação de múltiplas camadas em cinco namespaces.
Misconfigurações Validadas: Injeção experimental e validação de três classes críticas de misconfiguração (ausência de NetworkPolicies, RBAC excessivo e execução privilegiada) vinculadas a cenários de ataque reais.
Construção de Dataset Rotulado: Criação de um dataset contendo 3.180.125 fluxos rotulados (456 de origem de ataque, 3.179.669 benignos) derivados de 3,8 milhões de registros brutos, utilizando uma metodologia documentada de resolução de ground-truth de quatro versões para lidar com a arquitetura de múltiplos pontos de observação do Cilium.
Avaliação Comparativa: Uma comparação rigorosa entre um detector baseado em regras e um classificador Random Forest usando validação cruzada de janela temporal, análise de importância de características e testes de ablação.
Insight de Importância de Características: Identificação de que os atributos de identidade do lado do destino são os sinais discriminantes mais fortes na telemetria de fluxo do Kubernetes, exibindo uma razão de importância destino-origem de 2.8:1.

Resultados

Características do Dataset: O dataset final continha 456 fluxos de ataque (0,014% do total), confirmando um desequilíbrio de classes extremo. Os fluxos de ataque concentraram-se no PostgreSQL (5432), API de backend (8080) e HTTP (80).
Impacto do Ponto de Observação: Nenhum fluxo de ataque foi rotulado no ponto de observação TO_STACK devido à incompletude dos metadados de destino. Todos os 456 fluxos de ataque foram localizados em TO_ENDPOINT e TO_OVERWAY, onde os metadados eram suficientes para atribuição. Um teste qui-quadrado confirmou uma associação estatisticamente significativa entre os pontos de observação e os rótulos de ataque ( $\chi^2 = 2610.1, p < 0.001$ ).
Desempenho do Detector:
- Detector Baseado em Regras: Alcançou um AUPRC mais alto (0,311) comparado ao Random Forest (0,284), indicando precisão superior em pontos de operação de alta confiança. No entanto, teve um recall médio menor (0,746) do que o Random Forest (0,833).
- Random Forest: Alcançou um recall médio mais alto, mas com um AUPRC menor. Demonstrou uma cobertura mais ampla, mas produziu pontuações de probabilidade mais distribuídas.
Importância de Características: Atributos do lado do destino (dst_identity, dst_port, dst_namespace, dst_pod) representaram 64,2% da importância total de características, com uma razão destino-origem de 2,8:1. Testes de ablação confirmaram que a remoção das características de namespace e pod de destino reduziu o AUPRC em 7,4%.
Desempenho das Regras: A regra CROSS_NS_DB_ACCESS gerou o maior número de verdadeiros positivos (324), mas também o maior número de falsos positivos (425). A regra LATERAL_MOVEMENT teve maior precisão (0,556), porém um recall muito baixo (0,022).

Significância e Alegações

O artigo afirma que a telemetria Hubble/eBPF pode suportar efetivamente a detecção de ataques em tempo de execução em ambientes Kubernetes, desde que a arquitetura de múltiplos pontos de observação seja tratada com cuidado. O estudo enfatiza que:

A Construção de Ground-Truth é Crítica: A rotulagem ingênua de dados do Hubble leva a classes de ataque infladas ou incorretas. O processo de resolução de quatro versões proposto é essencial para criar datasets de segurança confiáveis.
O Contexto de Destino é a Chave: Diferente da detecção de intrusão de rede genérica, a detecção de ataques no Kubernetes depende fortemente de atributos de identidade do lado do destino para distinguir a intenção maliciosa (ex: um pod comprometido acessando um banco de dados entre namespaces).
Abordagens Complementares: Abordagens baseadas em regras e aprendizado de máquina oferecem forças complementares; regras fornecem alertas interpretáveis e de alta precisão, enquanto o aprendizado de máquina oferece uma cobertura de recall mais ampla.
Limitações: Os autores afirmam modestamente que, embora os resultados sejam promissores, são específicos para o testbed avaliado. A generalização para ambientes de produção maiores, diversos e multi-tenant requer validação adicional. O estudo não pretende resolver todos os problemas de segurança do Kubernetes, mas demonstra a viabilidade da telemetria de fluxo eBPF para detecção em tempo de execução quando combinada com engenharia de dados rigorosa.