La rivoluzione eBPF: Sicurezza e osservabilità senza strumentazione

27 febbraio 2026 | Tempo di lettura: 13 minuti 37 secondi

Introduzione: Il kernel come infrastruttura

Per decenni, l'osservabilità ha significato aggiungere codice alle tue applicazioni. Hai strumentato i tuoi servizi con librerie di metriche, seminato SDK di tracing attraverso i tuoi percorsi di chiamata e configurato log shipper su ogni host. Ogni livello di visibilità è venuto con un costo: gestione delle dipendenze, overhead di prestazioni, modifiche al codice che avevano bisogno di essere distribuite e mantenute. Perdere un endpoint e avevi un punto cieco. Aggiornare una libreria e rischiavi di rompere la tua pipeline di telemetria.

eBPF cambia questa equazione fondamentalmente. Invece di strumentare le applicazioni, strumenti il kernel. Ogni system call, ogni pacchetto di rete, ogni accesso ai file, ogni esecuzione di processo passa attraverso il kernel Linux — e eBPF ti consente di osservare e agire su questi eventi senza modificare le applicazioni che li generano. Nessuna modifica al codice. Nessuna dipendenza SDK. Nessun coordinamento della distribuzione.

Questo non è un miglioramento minore. È una categoria diversa di capacità. Quando il tuo layer di monitoraggio opera a livello di kernel, vedi tutto — incluse le cose che le applicazioni scelgono di non registrare, le connessioni di rete che bypassa la tua service mesh e i processi che il tuo container runtime non conosce.

L'ecosistema eBPF si è maturato rapidamente nel 2025 e nel 2026. Quello che era una volta una raccolta di progetti di ricerca e strumenti specializzati è diventato un'infrastruttura di produzione su scala. Cilium gestisce il networking per i principali provider di cloud. Falco fornisce sicurezza runtime per i cluster Kubernetes in tutto il mondo. Tetragon applica le politiche di sicurezza direttamente nel kernel. E strumenti come Coroot forniscono l'osservabilità full-stack — metriche, log, tracce e continuous profiling — da un singolo agente basato su eBPF che richiede modifiche zero alle applicazioni.

Questo articolo spiega cos'è eBPF, perché è importante per la sicurezza e l'osservabilità e come adottarlo nella pratica.

Cos'è effettivamente eBPF

eBPF sta per extended Berkeley Packet Filter, anche se il nome è principalmente storico a questo punto. L'eBPF moderno si è spinto ben oltre il filtraggio dei pacchetti.

Nel suo nucleo, eBPF è una macchina virtuale all'interno del kernel Linux che esegue programmi sandbox in risposta agli eventi del kernel. Questi programmi possono osservare le system call, il traffico di rete, le operazioni sui file, la pianificazione dei processi e essenzialmente qualsiasi attività a livello di kernel — il tutto senza modificare il kernel stesso o richiedere moduli del kernel.

Il modello di sicurezza

Quello che rende eBPF pratico è il suo modello di sicurezza. Prima che qualsiasi programma eBPF venga eseguito, il verificatore del kernel lo controlla esaustivamente:

Nessun ciclo illimitato: I programmi devono terminare. Il verificatore rifiuta i programmi che potrebbero essere eseguiti indefinitamente.
Nessun accesso alla memoria non valido: Ogni dereferenziamento di un puntatore è convalidato. I buffer overflow sono impossibili.
Limiti della dimensione dello stack: I programmi hanno una dimensione dello stack fissa (512 byte), prevenendo l'esaurimento dello stack.
Accesso alla funzione helper: I programmi possono solo chiamare funzioni helper del kernel pre-approvate, non codice kernel arbitrario.
Requisiti di privilegio: Il caricamento dei programmi eBPF richiede capacità appropriate (in genere CAP_BPF o root).

Questa verifica avviene al momento del caricamento, non al momento dell'esecuzione. Una volta che un programma passa il verificatore, funziona a velocità quasi nativa senza controlli di sicurezza runtime. Il risultato è l'osservabilità a livello di kernel con overhead di prestazioni trascurabile — in genere meno dell'1-2% di impatto CPU per un monitoraggio completo.

Punti di allegato

I programmi eBPF si allegano a eventi kernel specifici chiamati hook o punti di attacco:

Hook Type	Use Case	Example
kprobes	Tracciare qualsiasi funzione del kernel	Monitorare `sys_open` per tracciare l'accesso ai file
tracepoints	Eventi di traccia stable del kernel	Tracciare la creazione del processo tramite `sched_process_exec`
XDP	Elaborazione dei pacchetti di rete	Rilasciare i pacchetti dannosi prima che raggiungano lo stack di rete
TC	Controllo del traffico	Applicare le politiche di rete al livello del container
LSM	Hook del modulo di sicurezza Linux	Applicare le politiche di sicurezza sulle operazioni dei file
uprobe	Tracciamento della funzione nello spazio utente	Profilare funzioni specifiche dell'applicazione
perf events	Contatori di prestazioni della CPU	Continuous profiling CPU e memoria

L'ampiezza dei punti di attacco è quello che rende eBPF così potente. Un singolo agente basato su eBPF può simultaneamente monitorare il traffico di rete, l'accesso ai file, l'esecuzione dei processi, la risoluzione DNS e i modelli di system call — fornendo una visualizzazione unificata che tradizionalmente richiederebbe cinque o sei strumenti separati.

eBPF per l'osservabilità: Vedere tutto

L'osservabilità tradizionale ha tre pilastri: metriche, log e tracce. eBPF abilita tutti e tre senza strumentazione e aggiunge un quarto — continuous profiling — che è impraticabile con approcci a livello di applicazione.

Mappe di servizio senza strumentazione

Quando eBPF monitora le connessioni di rete a livello di kernel, vede ogni connessione TCP e UDP tra i servizi — incluse le connessioni che bypassa la tua service mesh, sidecar proxy o strumentazione a livello di applicazione. Questo abilita la scoperta automatica dei servizi e la mappatura delle dipendenze.

Strumenti come Coroot usano questa capacità per generare mappe di topologia live che mostrano tutte le dipendenze dei servizi. Nessuna modifica al codice necessaria. Nessun container sidecar. Nessuna configurazione per servizio. Distribuisci l'agente e entro pochi minuti vedi quali servizi comunicano con quali altri, la latenza di ogni connessione e i tassi di errore su ogni percorso.

Questo è particolarmente prezioso per:

Applicazioni legacy che non possono essere strumentate senza sforzi significativi
Servizi di terze parti in cui non controlli il codice
Ambienti poliglotta in cui diversi servizi usano diversi linguaggi e framework
Debug dei problemi di produzione in cui le dipendenze sconosciute causano guasti a cascata

Metriche consapevoli del protocollo

eBPF non vede solo le connessioni di rete — comprende i protocolli. Analizzando le intestazioni dei pacchetti a livello di kernel, gli agenti eBPF possono estrarre metriche a livello di applicazione senza alcuna consapevolezza dell'applicazione:

HTTP/HTTPS: Metodo di richiesta, percorso, codice di stato, latenza — equivalente a quello che otterresti da un log di accesso, ma catturato a livello di kernel per ogni servizio automaticamente.

Protocolli del database: PostgreSQL, MySQL, Redis e i protocolli wire MongoDB vengono analizzati per estrarre la latenza delle query, i tassi di errore e i conteggi delle connessioni. Questo significa che ottieni metriche di prestazioni del database senza installare alcun agente di monitoraggio del database o modificare le stringhe di connessione.

gRPC: Tracciamento della latenza a livello di metodo e tasso di errore per i servizi gRPC, catturato senza modificare la configurazione del framework gRPC.

DNS: Latenza di risoluzione e tassi di errore per ogni ricerca DNS, aiutando a identificare i problemi di prestazioni correlati a DNS che sono notoriamente difficili da debuggare con strumenti a livello di applicazione.

Kafka: Misurazioni del lag dei produttori e dei consumatori catturate a livello di protocollo, fornendo visibilità indipendente dal broker nelle prestazioni della pipeline dei messaggi.

Continuous Profiling

Forse la capacità più sottovalutata dell'osservabilità basata su eBPF è il continuous profiling. Il profiling tradizionale richiede l'allegato di un profiler a un processo specifico, l'esecuzione per un periodo e l'analisi dell'output. Questo è troppo dirompente e intensivo di risorse per l'uso in produzione.

Il profiling basato su eBPF funziona diversamente. Si allega agli eventi perf e campiona le stack trace della CPU a intervalli fissi su tutti i processi su un host. L'overhead è minimo — in genere meno dell'1% CPU — rendendolo fattibile per l'esecuzione continua in produzione.

Il valore pratico è significativo. Quando un servizio subisce uno spike di latenza, non hai bisogno di riprodurre il problema con un profiler allegato. I dati di profiling sono già lì, catturati come flame graph che mostrano esattamente dove è stato speso il tempo della CPU durante l'incidente. Questo trasforma il debugging delle prestazioni da un'investigazione reattiva a un'analisi retrospettiva.

eBPF per la sicurezza: Il kernel come primo intervento

L'osservabilità è solo metà della storia. eBPF è altrettanto trasformativo per la sicurezza runtime e la convergenza di osservabilità e sicurezza in un singolo agente a livello di kernel è uno dei più importanti cambiamenti architetturali nell'infrastruttura moderna.

Rilevamento delle minacce in tempo reale

Il monitoraggio della sicurezza tradizionale si basa sull'analisi dei log — esaminare i log dell'applicazione, i log di audit e i log di sistema per gli indicatori di compromesso. Questo approccio ha limitazioni fondamentali: gli attaccanti possono modificare o sopprimere i log, le applicazioni potrebbero non registrare eventi rilevanti per la sicurezza e la spedizione dei log introduce latenza tra un evento e il suo rilevamento.

Il monitoraggio della sicurezza basato su eBPF opera a un livello diverso. Allacciandosi alle system call e agli eventi del kernel, osserva attività che nessun log può sopprimere:

Esecuzione dei processi: Ogni processo generato su un sistema, inclusi quelli lanciati da exploit di container breakout
Accesso ai file: Ogni file aperto, letto, scritto o eliminato, incluso l'accesso a percorsi sensibili come /etc/shadow o chiavi crittografiche
Connessioni di rete: Ogni connessione in uscita, incluse quelle che bypassano le politiche di rete a livello di applicazione
Escalation dei privilegi: System call che modificano le capacità del processo, gli ID utente o i contesti di sicurezza
Caricamento del modulo del kernel: Tentativi di caricare moduli del kernel, che possono indicare l'installazione di rootkit

Applicazione della politica

Il rilevamento è prezioso, ma la prevenzione è meglio. Gli hook eBPF LSM (Linux Security Module) abilitano le politiche di sicurezza da applicare direttamente nel kernel, bloccando le azioni non autorizzate prima che diventino effettive.

Tetragon, sviluppato dal team di Cilium, è lo strumento leader in questo spazio. Fornisce:

Politiche di esecuzione dei processi: Definire quali binari è consentito eseguire in un container. Se una shell si genera all'interno di un container che dovrebbe solo eseguire un binario Go, Tetragon può bloccare l'esecuzione e generare un avviso.

Politiche di rete: Applicare quali destinazioni un pod può connettersi a livello di kernel, bypassando le potenziali vulnerabilità del container runtime.

Politiche di accesso ai file: Limitare quali file e directory un processo può accedere, fornendo difesa in profondità oltre i permessi del filesystem.

Restrizioni di capacità: Limitare quali capacità Linux un processo può esercitare, anche se il container runtime le concede.

L'applicazione avviene nel kernel, il che significa che non può essere bypassata da exploit a livello di applicazione. Un attaccante che ottiene l'esecuzione del codice all'interno di un container ancora non può eseguire azioni che la politica eBPF blocca, perché la politica viene applicata prima che la system call si completi.

Sicurezza della rete

Cilium, lo strumento basato su eBPF più ampiamente distribuito, ha ridefinito il funzionamento della sicurezza di rete negli ambienti Kubernetes. Le politiche di rete tradizionali operano a livello di indirizzo IP e porta. Le politiche basate su eBPF di Cilium operano a livello di identità e API:

Politiche basate su identità: Le politiche fanno riferimento ai label Kubernetes e alle identità dei servizi piuttosto che agli indirizzi IP, eliminando la necessità di tracciare le allocazioni IP dei pod
Filtraggio L7: Politiche consapevoli di HTTP, gRPC e Kafka che possono limitare l'accesso a endpoint API specifici, non solo porte
Crittografia trasparente: Crittografia basata su WireGuard tra i nodi, implementata nel kernel tramite eBPF senza richiedere modifiche all'applicazione
Gestione della larghezza di banda: Limiti di larghezza di banda per pod applicati a livello di kernel

L'ecosistema degli strumenti eBPF

L'ecosistema eBPF si è consolidato attorno a diversi progetti chiave, ognuno affrontando un dominio specifico.

Networking e Security

Tool	Purpose	Maintainer
Cilium	Networking Kubernetes, politica di rete, service mesh	Isovalent (Cisco)
Tetragon	Applicazione della sicurezza runtime	Isovalent (Cisco)
Falco	Rilevamento di minacce runtime	Sysdig / CNCF
Calico eBPF	Networking Kubernetes con datapath eBPF	Tigera

Observability

Tool	Purpose	Maintainer
Coroot	Osservabilità full-stack (metriche, log, tracce, profiling)	Coroot
Hubble	Osservabilità di rete per Cilium	Isovalent (Cisco)
Pixie	Osservabilità di Kubernetes	New Relic / CNCF
Parca	Continuous profiling	Polar Signals
Grafana Beyla	Auto-strumentazione per HTTP e gRPC	Grafana Labs

Tracing e Debugging

Tool	Purpose	Maintainer
bpftrace	Linguaggio di tracciamento di alto livello per eBPF	IO Visor
BCC	Toolkit BPF Compiler Collection	IO Visor
bpftool	Utilità di gestione dei programmi eBPF	Linux kernel

Adozione pratica: Iniziare

L'adozione di eBPF non richiede una profonda conoscenza del kernel. Gli strumenti eBPF moderni astraggono la complessità e presentano interfacce familiari — dashboard, avvisi e definizioni di politiche.

Iniziare con l'osservabilità

Il punto di ingresso a rischio più basso è l'osservabilità. Distribuisci un agente basato su eBPF come Coroot o Grafana Beyla insieme allo stack di monitoraggio esistente. L'agente non richiede modifiche all'applicazione — funziona come un container privilegiato o DaemonSet e inizia immediatamente a raccogliere metriche.

Per gli ambienti Kubernetes:

# Distribuire Coroot con 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

# Accedere al dashboard
kubectl port-forward -n coroot service/coroot-coroot 8080:8080

Entro pochi minuti vedrai una mappa di servizio, metriche di latenza per connessioni HTTP e di database e dati di utilizzo delle risorse — il tutto catturato senza alcuna modifica di strumentazione alle tue applicazioni.

Aggiungere l'applicazione della sicurezza

Una volta che l'osservabilità è in atto, il passo naturale successivo è l'applicazione della sicurezza. Tetragon fornisce un percorso graduato:

Fase 1: Modalità di audit. Distribuisci Tetragon con le politiche in modalità di audit. Registra le violazioni delle politiche senza bloccarle, dandoti il tempo di comprendere il comportamento della tua applicazione e affinare le politiche prima dell'applicazione.

Fase 2: Modalità di avviso. Connetti gli eventi di Tetragon al tuo sistema di avvisi. Ricevi notifiche quando si verifica attività sospetta — processi inaspettati, connessioni di rete non autorizzate, accesso a file sensibili.

Fase 3: Modalità di applicazione. Abilita l'applicazione sulle politiche che sono state convalidate in modalità di audit. Inizia con le restrizioni più critiche — prevenzione del breakout del container, ad esempio — e gradualmente espandi la copertura.

Requisiti del kernel

Le capacità eBPF dipendono dalla versione del kernel Linux. Per gli strumenti moderni di osservabilità e sicurezza eBPF, hai bisogno:

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+

La maggior parte dei servizi Kubernetes gestiti dal provider di cloud (EKS, GKE, AKS) eseguono kernel che supportano tutte le funzioni eBPF moderne. I deployment on-premises dovrebbero mirare al kernel 5.10 o successivo per la migliore compatibilità.

Considerazioni sulle prestazioni

Il monitoraggio eBPF aggiunge un overhead minimo, ma "minimo" non è "zero":

Overhead CPU: In genere 1-2% per il monitoraggio completo (rete, processo, file, profiling)
Utilizzo della memoria: 50-200 MB per nodo per l'agente, a seconda della cardinalità
Overhead di rete: Le metriche e gli eventi vengono spediti a un server centrale; l'utilizzo della larghezza di banda dipende dalla dimensione del cluster e dall'attività
Archiviazione: ClickHouse (utilizzato da Coroot) o Prometheus (utilizzato da molti strumenti) richiede l'archiviazione proporzionata al numero di servizi e al periodo di conservazione

Per la maggior parte degli ambienti, questi overhead sono trascurabili rispetto alla visibilità ottenuta. Tuttavia, i sistemi di trading ad altissima frequenza, l'elaborazione audio/video in tempo reale e altri carichi di lavoro critici per la latenza dovrebbero fare il benchmark degli strumenti eBPF attentamente prima della distribuzione in produzione.

La convergenza della sicurezza e dell'osservabilità

Il trend più significativo nell'ecosistema eBPF è la convergenza di sicurezza e osservabilità in piattaforme unificate. Storicamente, questi erano discipline separate con strumenti separati, team separati e budget separati. eBPF cancella il confine tecnico.

Quando un singolo agente a livello di kernel cattura le connessioni di rete, l'esecuzione dei processi, l'accesso ai file e i modelli di system call, gli stessi dati servono a entrambi gli scopi:

Osservabilità: "La latenza di Service A nel database è aumentata di 200 ms dopo l'ultimo deployment"
Sicurezza: "Un processo inaspettato si è generato nel container di Service A e ha fatto una connessione in uscita a un indirizzo IP sconosciuto"

Entrambe le osservazioni provengono dalla stessa fonte di dati eBPF. La differenza è nel modo in cui i dati vengono analizzati e quali azioni vengono attivate. Questa convergenza riduce il sprawl dell'agente (un agente invece di tre o quattro), elimina la duplicazione dei dati e abilita la correlazione che era precedentemente impossibile — come collegare un evento di sicurezza al suo impatto sulle prestazioni in tempo reale.

Strumenti come Coroot già incarnano questa convergenza, fornendo dashboard di osservabilità insieme al tracciamento SLO e al rilevamento di anomalie. Cilium e Tetragon insieme forniscono networking, osservabilità e applicazione della sicurezza da una singola piattaforma. Ci si aspetta che questa convergenza acceleri mentre l'ecosistema matura.

Conclusione: Il nuovo layer dell'infrastruttura

eBPF si è trasformato da una funzione del kernel Linux a un livello di infrastruttura fondamentale. È la tecnologia dietro il networking nella maggior parte dei principali cloud provider offerte Kubernetes. Alimenta le piattaforme di osservabilità che hanno sostituito gli agenti APM tradizionali. Applica le politiche di sicurezza che proteggono i container in tempo reale.

Per i team di ingegneria, il takeaway pratico è semplice: se stai eseguendo carichi di lavoro Linux — specialmente in Kubernetes — gli strumenti basati su eBPF dovrebbero far parte del tuo stack di infrastruttura. L'osservabilità che ottieni senza alcuna modifica al codice è notevole. L'applicazione della sicurezza che puoi aggiungere senza modifiche all'applicazione è trasformativa. E la convergenza di entrambe le capacità in piattaforme unificate semplifica le operazioni in modi che gli stack di strumenti separati non potrebbero mai fare.

Inizia con l'osservabilità. Aggiungi l'applicazione della sicurezza gradualmente. Lascia che il kernel faccia il lavoro che stai chiedendo alle tue applicazioni di fare. I risultati ne varranno la pena.