A Revolução eBPF: Segurança e Observabilidade Sem Instrumentação

27 de fevereiro de 2026 | Tempo de leitura: 13 minutos 37 segundos

Introdução: O Kernel como Infraestrutura

Por décadas, observabilidade significava adicionar código às suas aplicações. Você instrumentava seus serviços com bibliotecas de métricas, espalhava SDKs de tracing através de seus caminhos de chamada e configurava shippers de log em cada host. Cada camada de visibilidade veio com um custo: gerenciamento de dependência, overhead de desempenho, mudanças de código que precisavam ser implantadas e mantidas. Perder um endpoint e você tinha um blind spot. Atualizar uma biblioteca e você arriscava quebrar seu pipeline de telemetria.

eBPF muda esta equação fundamentalmente. Em vez de instrumentar aplicações, você instrumenta o kernel. Cada chamada de sistema, cada pacote de rede, cada acesso a arquivo, cada execução de processo passa através do kernel Linux — e eBPF deixa você observar e agir sobre estes eventos sem modificar as aplicações que os geram. Nenhuma mudança de código. Nenhuma dependência de SDK. Nenhuma coordenação de implantação.

Esta não é uma melhoria menor. É uma categoria diferente de capacidade. Quando sua camada de monitoramento opera no nível do kernel, você vê tudo — incluindo as coisas que aplicações escolhem não registrar, as conexões de rede que contornam seu service mesh e os processos que seu container runtime não conhece.

O ecossistema eBPF amadureceu rapidamente durante 2025 e em 2026. O que era uma coleção de projetos de pesquisa e ferramentas especializadas se tornou infraestrutura de produção em escala. Cilium lida com rede para grandes provedores de nuvem. Falco fornece segurança em tempo de execução para clusters Kubernetes em todo o mundo. Tetragon impõe políticas de segurança diretamente no kernel. E ferramentas como Coroot entregam observabilidade full-stack — métricas, logs, traces e criação contínua de perfil — de um único agente baseado em eBPF que requer nenhuma mudança de aplicação.

Este artigo explica o que é eBPF, por que importa para segurança e observabilidade, e como adotá-lo na prática.

O Que eBPF Realmente É

eBPF significa extended Berkeley Packet Filter, embora o nome seja principalmente histórico neste ponto. eBPF moderno se moveu muito além de filtragem de pacotes.

Em seu núcleo, eBPF é uma máquina virtual dentro do kernel Linux que executa programas em sandbox em resposta a eventos do kernel. Estes programas podem observar chamadas de sistema, tráfego de rede, operações de arquivo, agendamento de processo e essencialmente qualquer atividade de nível de kernel — tudo sem modificar o kernel em si ou exigindo módulos de kernel.

O Modelo de Segurança

O que torna eBPF prático é seu modelo de segurança. Antes de qualquer programa eBPF rodar, o verificador do kernel o verifica exaustivamente:

Sem loops ilimitados: Programas devem terminar. O verificador rejeita programas que poderiam rodar indefinidamente.
Sem acesso inválido de memória: Cada dereferência de ponteiro é validada. Overflows de buffer são impossíveis.
Limites de tamanho de stack: Programas têm um tamanho de stack fixo (512 bytes), prevenindo esgotamento de stack.
Acesso de função auxiliar: Programas podem apenas chamar funções auxiliares pré-aprovadas do kernel, não código arbitrário do kernel.
Requisitos de privilégio: Carregar programas eBPF requer capacidades apropriadas (tipicamente CAP_BPF ou root).

Esta verificação acontece em tempo de carregamento, não em tempo de execução. Uma vez que um programa passa pelo verificador, funciona na velocidade quase nativa sem verificações de segurança em tempo de execução. O resultado é observabilidade de nível de kernel com overhead de desempenho negligenciável — tipicamente menos de 1-2% de impacto de CPU para monitoramento abrangente.

Pontos de Anexação

Programas eBPF se anexam a eventos específicos do kernel chamados hooks ou pontos de anexação:

Hook Type	Use Case	Example
kprobes	Trace any kernel function	Monitor `sys_open` to track file access
tracepoints	Stable kernel trace events	Track process creation via `sched_process_exec`
XDP	Network packet processing	Drop malicious packets before they reach the network stack
TC	Traffic control	Apply network policies at the container level
LSM	Linux Security Module hooks	Enforce security policies on file operations
uprobe	User-space function tracing	Profile specific application functions
perf events	CPU performance counters	Continuous CPU and memory profiling

A amplitude de pontos de anexação é o que torna eBPF tão poderoso. Um único agente baseado em eBPF pode simultaneamente monitorar tráfego de rede, acesso de arquivo, execução de processo, resolução DNS e padrões de chamadas de sistema — fornecendo uma visão unificada que tradicionalmente exigiria cinco ou seis ferramentas separadas.

eBPF para Observabilidade: Vendo Tudo

Observabilidade tradicional tem três pilares: métricas, logs e traces. eBPF habilita todos os três sem instrumentação, e adiciona um quarto — criação contínua de perfil — que é impraticável com abordagens de nível de aplicação.

Mapas de Serviço de Zero-Instrumentação

Quando eBPF monitora conexões de rede no nível do kernel, vê cada conexão TCP e UDP entre serviços — incluindo conexões que contornam seu service mesh, sidecars proxies ou instrumentação de nível de aplicação. Isto habilita descoberta automática de serviço e mapeamento de dependência.

Ferramentas como Coroot usam esta capacidade para gerar mapas de topologia ao vivo mostrando todas as dependências de serviço. Nenhuma mudança de código necessária. Nenhum container sidecar. Nenhuma configuração por serviço. Implante o agente e em minutos veja quais serviços se comunicam com quais outros, a latência de cada conexão e as taxas de erro em cada caminho.

Isto é particularmente valioso para:

Aplicações legadas que não podem ser instrumentadas sem esforço significativo
Serviços terceirizados onde você não controla o código
Ambientes poliglotas onde diferentes serviços usam diferentes linguagens e frameworks
Debugging de questões de produção onde dependências desconhecidas causam falhas em cascata

Métricas Cientes de Protocolo

eBPF não apenas vê conexões de rede — compreende protocolos. Analisando cabeçalhos de pacotes no nível do kernel, agentes eBPF podem extrair métricas de camada de aplicação sem nenhuma consciência de aplicação:

HTTP/HTTPS: Método de requisição, caminho, código de status, latência — equivalente ao que você teria de um access log, mas capturado no nível do kernel para cada serviço automaticamente.

Protocolos de banco de dados: PostgreSQL, MySQL, Redis e MongoDB protocolos de fio são analisados para extrair latência de query, taxas de erro e contagens de conexão. Isto significa que você obtém métricas de desempenho de banco de dados sem instalar qualquer agente de monitoramento de banco de dados ou modificar strings de conexão.

gRPC: Rastreamento de latência de nível de método e rastreamento de erro para serviços gRPC, capturado sem modificar a configuração de framework gRPC.

DNS: Latência de resolução e taxas de falha para cada lookup de DNS, ajudando a identificar questões relacionadas a DNS que são notoriamente difíceis de debugar com ferramentas de nível de aplicação.

Kafka: Medições de lag de produtor e consumidor capturadas no nível de protocolo, fornecendo visibilidade broker-independent no desempenho de pipeline de mensagem.

Criação Contínua de Perfil

Talvez a capacidade mais subestimada de observabilidade baseada em eBPF seja criação contínua de perfil. Profiling tradicional requer anexar um profiler a um processo específico, executá-lo por um período e analisar a saída. Isto é muito disruptivo e intensivo em recursos para uso de produção.

Profiling baseado em eBPF funciona diferentemente. Se anexa a perf events e amostra stack traces de CPU em intervalos fixos em todos os processos em um host. O overhead é mínimo — tipicamente menos de 1% de CPU — tornando viável executar continuamente em produção.

O valor prático é significativo. Quando um serviço experimenta um spike de latência, você não precisa reproduzir o problema com um profiler anexado. Os dados de profiling já estão lá, capturados como flame graphs que mostram exatamente onde o tempo de CPU foi gasto durante o incidente. Isto transforma debugging de desempenho de uma investigação reativa em uma análise retrospectiva.

eBPF para Segurança: O Kernel como Primeiro Respondente

Observabilidade é apenas metade da história. eBPF é igualmente transformativo para segurança em tempo de execução, e a convergência de observabilidade e segurança em um único agente de nível de kernel é uma das mudanças arquiteturais mais importantes em infraestrutura moderna.

Detecção de Ameaça em Tempo de Execução

Monitoramento de segurança tradicional se baseia em análise de log — examinando logs de aplicação, logs de auditoria e logs de sistema para indicadores de comprometimento. Esta abordagem tem limitações fundamentais: atacantes podem modificar ou suprimir logs, aplicações podem não registrar eventos relevantes de segurança e log shipping introduz latência entre um evento e sua detecção.

Monitoramento de segurança baseado em eBPF opera em um nível diferente. Ao se conectar a chamadas de sistema e eventos de kernel, observa atividades que nenhum log pode suprimir:

Execução de processo: Cada processo gerado em um sistema, incluindo aqueles lançados por exploits de breakout de container
Acesso de arquivo: Cada arquivo aberto, lido, escrito ou deletado, incluindo acesso a caminhos sensíveis como /etc/shadow ou chaves criptográficas
Conexões de rede: Cada conexão de saída, incluindo aquelas que contornam políticas de rede de nível de aplicação
Escalação de privilégio: Chamadas de sistema que modificam capacidades de processo, IDs de usuário ou contextos de segurança
Carregamento de módulo de kernel: Tentativas de carregar módulos de kernel, que podem indicar instalação de rootkit

Imposição de Política

Detecção é valiosa, mas prevenção é melhor. Hooks eBPF LSM (Linux Security Module) habilitam políticas de segurança a serem impostas diretamente no kernel, bloqueando ações não autorizadas antes de terem efeito.

Tetragon, desenvolvido pelo time de Cilium, é a ferramenta líder neste espaço. Fornece:

Políticas de execução de processo: Defina quais binários têm permissão para executar em um container. Se um shell gera dentro de um container que deveria apenas executar um binário Go, Tetragon pode bloquear a execução e gerar um alerta.

Políticas de rede: Imponha para quais destinos um pod pode se conectar no nível do kernel, contornando vulnerabilidades potenciais de container runtime.

Políticas de acesso de arquivo: Restrinja quais arquivos e diretórios um processo pode acessar, fornecendo defesa em profundidade além de permissões de filesystem.

Restrições de capacidade: Limite quais capacidades Linux um processo pode exercer, mesmo se o container runtime as conceder.

A imposição acontece no kernel, o que significa que não pode ser contornada por exploits de nível de aplicação. Um atacante que ganha execução de código dentro de um container ainda não pode realizar ações que a política eBPF bloqueia, porque a política é imposta antes da chamada de sistema completar.

Segurança de Rede

Cilium, a ferramenta de rede baseada em eBPF mais amplamente implantada, redefiniu como segurança de rede funciona em ambientes Kubernetes. Políticas de rede tradicionais operam no nível de endereço IP e porta. Políticas baseadas em eBPF de Cilium operam no nível de identidade e API:

Políticas baseadas em identidade: Políticas referenciam labels Kubernetes e identidades de serviço em vez de endereços IP, eliminando a necessidade de rastrear alocações de IP de pod
Filtragem L7: Políticas cientes de HTTP, gRPC e Kafka que podem restringir acesso a endpoints de API específicos, não apenas portas
Criptografia transparente: Criptografia baseada em WireGuard entre nós, implementada no kernel via eBPF sem exigir mudanças de aplicação
Gerenciamento de largura de banda: Limites de largura de banda por pod impostos no nível do kernel

O Ecossistema de Ferramentas eBPF

O ecossistema eBPF consolidou-se em torno de vários projetos chave, cada um endereçando um domínio específico.

Rede e Segurança

Tool	Purpose	Maintainer
Cilium	Kubernetes networking, network policy, service mesh	Isovalent (Cisco)
Tetragon	Runtime security enforcement	Isovalent (Cisco)
Falco	Runtime threat detection	Sysdig / CNCF
Calico eBPF	Kubernetes networking with eBPF datapath	Tigera

Observabilidade

Tool	Purpose	Maintainer
Coroot	Full-stack observability (metrics, logs, traces, profiling)	Coroot
Hubble	Network observability for Cilium	Isovalent (Cisco)
Pixie	Kubernetes observability	New Relic / CNCF
Parca	Continuous profiling	Polar Signals
Grafana Beyla	Auto-instrumentation for HTTP and gRPC	Grafana Labs

Tracing e Debugging

Tool	Purpose	Maintainer
bpftrace	High-level tracing language for eBPF	IO Visor
BCC	BPF Compiler Collection toolkit	IO Visor
bpftool	eBPF program management utility	Linux kernel

Adoção Prática: Começando

Adotar eBPF não requer conhecimento profundo de kernel. Ferramentas eBPF modernas abstraem a complexidade e apresentam interfaces familiares — dashboards, alertas e definições de política.

Começando com Observabilidade

O ponto de entrada de menor risco é observabilidade. Implante um agente baseado em eBPF como Coroot ou Grafana Beyla junto com seu stack de monitoramento existente. O agente requer nenhuma mudança de aplicação — funciona como um container privilegiado ou DaemonSet e imediatamente começa a coletar métricas.

Para ambientes Kubernetes:

# Deploy Coroot with Helm
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce

# Access the dashboard
kubectl port-forward -n coroot service/coroot-coroot 8080:8080

Em minutos, você verá um mapa de serviço, métricas de latência para conexões HTTP e banco de dados e dados de utilização de recursos — tudo capturado sem qualquer mudança de instrumentação para suas aplicações.

Adicionando Imposição de Segurança

Uma vez que observabilidade esteja no lugar, o próximo passo natural é imposição de segurança. Tetragon fornece um caminho graduado:

Fase 1: Modo de auditoria. Implante Tetragon com políticas em modo de auditoria. Registra violações de política sem bloqueá-las, dando tempo para compreender o comportamento de sua aplicação e refinar políticas antes da imposição.

Fase 2: Modo de alerta. Conecte eventos de Tetragon ao seu sistema de alertas. Receba notificações quando atividade suspeita ocorre — processos inesperados, conexões de rede não autorizadas, acesso a arquivo sensível.

Fase 3: Modo de imposição. Habilite imposição em políticas que foram validadas em modo de auditoria. Comece com restrições mais críticas — prevenção de breakout de container, por exemplo — e gradualmente expanda cobertura.

Requisitos de Kernel

As capacidades de eBPF dependem da versão do kernel Linux. Para observabilidade e ferramentas de segurança eBPF modernas, você precisa:

Feature	Minimum Kernel	Recommended
Basic eBPF	4.4	5.10+
BTF support	5.2	5.10+
LSM hooks	5.7	5.15+
BPF tokens	6.9	6.9+
Ring buffer	5.8	5.10+

A maioria dos serviços Kubernetes gerenciados de provedores de nuvem (EKS, GKE, AKS) executam kernels que suportam todas as características eBPF modernas. Implementações on-premises devem almejar kernel 5.10 ou posterior para a melhor compatibilidade.

Considerações de Desempenho

Monitoramento eBPF adiciona overhead mínimo, mas "mínimo" não é "zero":

Overhead de CPU: Tipicamente 1-2% para monitoramento abrangente (rede, processo, arquivo, profiling)
Uso de memória: 50-200 MB por nó para o agente, dependendo da cardinalidade
Overhead de rede: Métricas e eventos são enviados para um servidor central; uso de largura de banda depende do tamanho do cluster e atividade
Armazenamento: ClickHouse (usado por Coroot) ou Prometheus (usado por muitas ferramentas) requer armazenamento proporcional ao número de serviços e período de retenção

Para a maioria dos ambientes, estes overheads são negligenciáveis comparado à visibilidade obtida. Entretanto, sistemas de trading de alta frequência, processamento de áudio/vídeo em tempo real e outras cargas de trabalho latency-críticas devem fazer benchmarking de ferramentas eBPF cuidadosamente antes de implantação de produção.

A Convergência de Segurança e Observabilidade

A tendência mais significativa no ecossistema eBPF é a convergência de segurança e observabilidade em plataformas unificadas. Historicamente, estes eram disciplinas separadas com ferramentas separadas, times separados e orçamentos separados. eBPF apaga a fronteira técnica.

Quando um único agente de nível de kernel captura conexões de rede, execução de processo, acesso de arquivo e padrões de chamadas de sistema, os mesmos dados servem ambos os propósitos:

Observabilidade: "A latência de Service A para o banco de dados aumentou 200ms após a última implantação"
Segurança: "Um processo inesperado gerou no container de Service A e fez uma conexão de saída para um IP desconhecido"

Ambas as observações vêm da mesma fonte de dados eBPF. A diferença é em como os dados são analisados e quais ações são disparadas. Esta convergência reduz sprawl de agente (um agente em vez de três ou quatro), elimina duplicação de dados e habilita correlação que era anteriormente impossível — como vincular um evento de segurança ao seu impacto de desempenho em tempo real.

Ferramentas como Coroot já incorporam esta convergência, fornecendo dashboards de observabilidade junto com rastreamento SLO e detecção de anomalia. Cilium e Tetragon juntos fornecem rede, observabilidade e imposição de segurança a partir de uma única plataforma. Espere que esta convergência se acelere conforme o ecossistema amadurece.

Conclusão: A Nova Camada de Infraestrutura

eBPF se moveu de um recurso de kernel Linux para uma camada de infraestrutura fundamental. É a tecnologia por trás de rede na maioria das ofertas de Kubernetes de grandes provedores de nuvem. Ela potencia as plataformas de observabilidade que substituíram agentes APM tradicionais. Ela impõe as políticas de segurança que protegem containers em tempo de execução.

Para times de engenharia, o takeaway prático é direto: se você está executando cargas de trabalho Linux — especialmente em Kubernetes — ferramentas baseadas em eBPF devem ser parte do seu stack de infraestrutura. A observabilidade que você obtém sem nenhuma mudança de código é notável. A imposição de segurança que você pode adicionar sem modificações de aplicação é transformativa. E a convergência de ambas as capacidades em plataformas unificadas simplifica operações de maneiras que stacks de ferramentas separadas nunca puderam.

Comece com observabilidade. Adicione imposição de segurança gradualmente. Deixe o kernel fazer o trabalho que você esteve pedindo às suas aplicações para fazer. Os resultados valerão a pena.