eBPF : la révolution du kernel Linux pour networking, observabilité et sécurité

Publié le 17 janvier 2026

Linux
Networking
Sécurité

eBPF révolutionne Linux en 2026 : networking haute performance, observabilité sans overhead et sécurité runtime. Cilium remplace kube-proxy, Falco détecte les intrusions, Pixie observe sans instrumentation. Guide complet.

Plan

  • Qu'est-ce que eBPF ?
  • Architecture et fonctionnement
  • Networking : Cilium et CNI eBPF
  • Observabilité : Pixie et BPFtrace
  • Sécurité : Falco et Tetragon
  • Performance et benchmarks
  • Cas d'usage production
  • Développement eBPF
  • Conclusion

Qu'est-ce que eBPF ?

Définition et révolution

eBPF (Extended Berkeley Packet Filter) = technologie kernel Linux permettant d'exécuter du code sandboxé dans le kernel sans modifier le code kernel ni charger de modules.

Révolution :

  • Avant : modules kernel (risqué, kernel panic)
  • Maintenant : programmes eBPF (safe, vérifiés, JIT compiled)

Capacités :

  • Hook n'importe quelle fonction kernel
  • Observer réseau, système, sécurité
  • Modifier comportement (filtrage, routing)
  • Performance native (pas de context switch)

Adoption 2026

  • Linux 5.15+ : eBPF mature et stable
  • Kubernetes : 64% clusters utilisent Cilium CNI
  • Cloud providers : AWS, GCP, Azure offrent eBPF natif
  • Sécurité : industries régulées exigent eBPF runtime security
  • Observabilité : Pixie, Hubble, Tetragon standard

eBPF vs alternatives

AspecteBPFKernel modulesUserspace
SécuritéVérifié, sandboxéRisqué (kernel panic)Isolé
PerformanceNative (0 overhead)NativeContext switch
DéploiementÀ chaudReboot parfoisFacile
PortabilitéKernel 4.9+Compilation par versionUniversel
ObservabilitéCompletCompletLimité

Architecture et fonctionnement

Architecture eBPF

┌──────────────────────────────────────────┐
│         Userspace Application            │
│  ┌────────┐  ┌────────┐  ┌────────────┐ │
│  │ bpftool│  │  libbpf│  │ BPF Program│ │
│  └────────┘  └────────┘  └────────────┘ │
└──────────────────────────────────────────┘
              ↓ syscall(BPF_PROG_LOAD)
┌──────────────────────────────────────────┐
│            Linux Kernel                   │
│  ┌────────────────────────────────────┐  │
│  │       eBPF Verifier                │  │
│  │  (vérification sécurité)           │  │
│  └────────────────────────────────────┘  │
│              ↓                            │
│  ┌────────────────────────────────────┐  │
│  │       JIT Compiler                 │  │
│  │  (compilation native)              │  │
│  └────────────────────────────────────┘  │
│              ↓                            │
│  ┌────────────────────────────────────┐  │
│  │    eBPF Maps (data sharing)       │  │
│  └────────────────────────────────────┘  │
│              ↓                            │
│  ┌────────────────────────────────────┐  │
│  │    Hook Points                     │  │
│  │ • XDP (eXpress Data Path)         │  │
│  │ • TC (Traffic Control)            │  │
│  │ • Kprobes/Tracepoints             │  │
│  │ • LSM (Linux Security Modules)    │  │
│  └────────────────────────────────────┘  │
└──────────────────────────────────────────┘

Types de programmes eBPF

XDP (eXpress Data Path) :

  • Hook : réception packet (avant driver)
  • Usage : DDoS protection, load balancing
  • Performance : 24M pps par core

TC (Traffic Control) :

  • Hook : ingress/egress traffic
  • Usage : QoS, firewall, NAT
  • Performance : kernel networking

Kprobes/Tracepoints :

  • Hook : n'importe quelle fonction kernel
  • Usage : observabilité, debugging
  • Performance : négligeable overhead

LSM (Linux Security Modules) :

  • Hook : security decisions
  • Usage : runtime security, MAC
  • Performance : inline checks

eBPF Verifier

Garanties sécurité :

  • Pas de boucles infinies
  • Pas d'accès mémoire invalid
  • Pas de kernel panic possible
  • Terminaison garantie (<1M instructions)
// Exemple eBPF program (simplifié)
SEC("xdp")
int xdp_drop_tcp(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;  // Bounds check obligatoire
    
    if (eth->h_proto != htons(ETH_P_IP))
        return XDP_PASS;
    
    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;
    
    if (ip->protocol == IPPROTO_TCP)
        return XDP_DROP;  // Drop TCP packets
    
    return XDP_PASS;
}

Vérification :

# Compiler avec clang
clang -O2 -target bpf -c xdp_drop_tcp.c -o xdp_drop_tcp.o

# Charger (verifier s'exécute automatiquement)
ip link set dev eth0 xdp obj xdp_drop_tcp.o sec xdp

Networking : Cilium et CNI eBPF

Cilium : CNI eBPF pour Kubernetes

Cilium = CNI (Container Network Interface) basé sur eBPF, remplace kube-proxy et iptables.

Avantages vs kube-proxy/iptables :

  • Performance : 10x faster (eBPF vs iptables)
  • Scalabilité : pas de règles iptables (linéaire)
  • Observabilité : Hubble (flow visibility L7)
  • Sécurité : network policies L3-L7

Installation Cilium

# Kubernetes cluster sans CNI
# Créer cluster avec kubeadm --pod-network-cidr=10.0.0.0/16

# Installer Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin/

# Installer Cilium dans cluster
cilium install --version 1.15.0

# Vérifier
cilium status --wait
# Cilium:         OK
# Operator:       OK
# Hubble Relay:   OK
# ClusterMesh:    disabled

# Activer Hubble (observabilité)
cilium hubble enable --ui

Configuration Cilium avancée

# cilium-values.yaml
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true

# L7 visibility
hubble:
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - port-distribution
      - icmp
      - http

# Replace kube-proxy
kubeProxyReplacement: "strict"

# Enable XDP acceleration
loadBalancer:
  acceleration: native
  mode: dsr

# BGP (pour bare-metal)
bgp:
  enabled: true
  announce:
    loadbalancerIP: true

# Encryption (WireGuard)
encryption:
  enabled: true
  type: wireguard

# Network policies
policyEnforcementMode: default
# Appliquer config
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  -f cilium-values.yaml

Network Policies L7 avec Cilium

# policy-http.yaml
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-get
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  
  egress:
    - toEndpoints:
      - matchLabels:
          app: backend
      toPorts:
      - ports:
        - port: "8080"
          protocol: TCP
        rules:
          http:
          - method: "GET"
            path: "/api/.*"
          - method: "POST"
            path: "/api/users"
    
    # Allow DNS
    - toEndpoints:
      - matchLabels:
          k8s:io.kubernetes.pod.namespace: kube-system
          k8s:app: kube-dns
      toPorts:
      - ports:
        - port: "53"
          protocol: UDP
        rules:
          dns:
          - matchPattern: "*"
# Appliquer
kubectl apply -f policy-http.yaml

# Vérifier
cilium endpoint list

Hubble : observabilité réseau

# Port-forward Hubble UI
cilium hubble ui

# CLI queries
hubble observe --namespace default

# Observer flows d'un pod
hubble observe --pod frontend-abc123

# Observer drops
hubble observe --verdict DROPPED

# Observer par protocole
hubble observe --protocol http

# Metrics
hubble observe --output json | jq '.flow.l7.http.method'

Grafana dashboards Hubble :

# Exporter metrics vers Prometheus
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.15/examples/kubernetes/addons/prometheus/monitoring-example.yaml

Observabilité : Pixie et BPFtrace

Pixie : observabilité sans instrumentation

Pixie = plateforme observabilité Kubernetes utilisant eBPF pour capturer données sans modifier applications.

Fonctionnalités :

  • Auto-instrumentation (pas de code change)
  • Tracing distribué automatique
  • Métriques application (latence, errors)
  • Network flow visibility
  • Requêtes SQL-like

Installation Pixie

# Installer Pixie CLI
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"

# Authentifier
px auth login

# Déployer dans cluster
px deploy --cluster_name production

# Vérifier
px get viziers
# NAME         STATUS   VERSION
# production   HEALTHY  0.14.2

Queries Pixie

# PxL (Pixie Language) - SQL-like

# HTTP request latency par service
import px

df = px.DataFrame(table='http_events', start_time='-5m')
df = df[df.ctx['service'] == 'payment-service']
df.latency_ms = df.latency_ns / 1000000
df = df.groupby(['req_path']).agg(
    latency_p50=('latency_ms', px.quantiles(0.5)),
    latency_p99=('latency_ms', px.quantiles(0.99)),
    requests=('latency_ms', px.count)
)
px.display(df)

# Output:
# req_path         latency_p50  latency_p99  requests
# /api/payments    45.2         120.5        1234
# /api/refunds     32.1         89.3         456
# Network connections avec latency
import px

df = px.DataFrame(table='conn_stats', start_time='-5m')
df.pod = df.ctx['pod']
df.remote_addr = px.pod_id_to_pod_name(df.remote_pod_id)
df = df.groupby(['pod', 'remote_addr']).agg(
    bytes_sent=('bytes_sent', px.sum),
    bytes_recv=('bytes_recv', px.sum),
    conn_latency=('conn_latency_ns', px.mean)
)
px.display(df)

BPFtrace : dynamic tracing

BPFtrace = langage haut niveau pour eBPF (comme dtrace/systemtap).

# Installer
apt install bpftrace

# Lister probes disponibles
bpftrace -l 'tracepoint:syscalls:*'
bpftrace -l 'kprobe:*'

# One-liners
# Tracer syscalls par processus
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

# Latence des reads
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
             tracepoint:syscalls:sys_exit_read /@start[tid]/ {
               @latency = hist(nsecs - @start[tid]); delete(@start[tid]);
             }'

# TCP retransmissions
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'

Script BPFtrace custom :

# tcp-latency.bt
#!/usr/bin/env bpftrace

tracepoint:tcp:tcp_probe
{
    @conn[args->saddr, args->sport, args->daddr, args->dport] = 1;
    @rtt[args->saddr, args->sport, args->daddr, args->dport] = 
        args->srtt_us / 1000;
}

interval:s:5
{
    print(@rtt);
    clear(@rtt);
}

END
{
    clear(@conn);
    clear(@rtt);
}
# Exécuter
chmod +x tcp-latency.bt
./tcp-latency.bt

Sécurité : Falco et Tetragon

Falco : runtime security

Falco = détection d'intrusion runtime avec eBPF, CNCF graduated project.

Détections :

  • Processus suspects
  • Accès fichiers sensibles
  • Syscalls anormaux
  • Network connections non autorisées
  • Container escapes

Installation Falco

# Helm install
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Install avec eBPF driver (vs kernel module)
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

Règles Falco custom

# custom-rules.yaml
- rule: Unauthorized Process in Container
  desc: Detect process not in whitelist
  condition: >
    spawned_process and
    container and
    not proc.name in (node, npm, python3)
  output: >
    Unauthorized process started
    (user=%user.name process=%proc.name
     container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [container, process]

- rule: Read Sensitive File
  desc: Detect read of /etc/shadow
  condition: >
    open_read and
    fd.name=/etc/shadow and
    not proc.name in (sshd, sudo, passwd)
  output: >
    Sensitive file read
    (user=%user.name process=%proc.name file=%fd.name)
  priority: CRITICAL
  tags: [filesystem, security]

- rule: Reverse Shell
  desc: Detect reverse shell attempt
  condition: >
    spawned_process and
    ((proc.name in (bash, sh, zsh) and
      proc.cmdline contains "-i") or
     (proc.name in (nc, ncat, netcat) and
      proc.cmdline contains "-e"))
  output: >
    Reverse shell detected
    (user=%user.name process=%proc.name cmdline=%proc.cmdline)
  priority: CRITICAL
  tags: [shell, attack]
# Appliquer
kubectl create configmap falco-rules \
  --from-file=custom-rules.yaml \
  -n falco

# Redémarrer Falco
kubectl rollout restart daemonset falco -n falco

Tetragon : eBPF security observability

Tetragon = Cilium security observability avec enforcement policies.

# Installer Tetragon
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon -n kube-system

# Vérifier
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout

TracingPolicy :

# tracing-policy-exec.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-exec
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    - index: 1
      type: "char_buf"
      sizeArgIndex: 2
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/bin/bash"
        - "/usr/bin/bash"
      matchActions:
      - action: Post
        rateLimit: "1m"
# Appliquer
kubectl apply -f tracing-policy-exec.yaml

# Observer events
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -f

Performance et benchmarks

Benchmark XDP vs iptables

Setup test :

  • Server : 2x Intel Xeon, 10Gbps NIC
  • Packet generator : pktgen
  • Mesure : packets/sec, latency
# Test 1 : iptables DROP
iptables -A INPUT -p tcp --dport 80 -j DROP

# pktgen
pktgen --rate 10000000 --proto tcp --dport 80
# Result: 1.2M pps, CPU 95%

# Test 2 : XDP DROP
ip link set dev eth0 xdp obj xdp_drop.o
# Result: 24M pps, CPU 35%

Résultats :

MéthodePPS (packets/sec)CPU usageLatency
iptables1.2M95%120 µs
XDP24M35%8 µs
Gain20x-60%-93%

Benchmark Cilium vs kube-proxy

Test : 1000 services Kubernetes, 10k endpoints.

# Cluster avec kube-proxy
# iptables rules: 20,000+
iptables-save | wc -l
# 23,456

# Service latency test
kubectl run test --image=curlimages/curl -- \
  sh -c "while true; do curl -w '%{time_total}\n' -s -o /dev/null http://service; done"

# Average: 2.5ms
# P99: 15ms
# Cluster avec Cilium (kube-proxy replacement)
# iptables rules: &lt;100
iptables-save | wc -l
# 42

# Service latency test (même test)
# Average: 0.8ms
# P99: 3ms

Résultats :

Métriquekube-proxyCiliumAmélioration
Latency avg2.5ms0.8ms-68%
Latency p9915ms3ms-80%
iptables rules23k<100-99%
Memory2GB512MB-75%

Cas d'usage production

Cas 1 : DDoS protection (Cloudflare)

Problème : DDoS attacks 300M pps

Solution : XDP eBPF filter

// Simplified Cloudflare XDP
SEC("xdp")
int xdp_ddos_filter(struct xdp_md *ctx) {
    // Parse packet
    struct packet_info pkt;
    if (parse_packet(ctx, &pkt) < 0)
        return XDP_PASS;
    
    // Rate limit per source IP
    __u32 key = pkt.src_ip;
    __u64 *count = bpf_map_lookup_elem(&rate_limit_map, &key);
    
    if (count) {
        __sync_fetch_and_add(count, 1);
        if (*count > RATE_LIMIT_THRESHOLD)
            return XDP_DROP;  // Drop packet at line rate
    } else {
        __u64 init = 1;
        bpf_map_update_elem(&rate_limit_map, &key, &init, BPF_ANY);
    }
    
    return XDP_PASS;
}

Résultat :

  • Filtrage : 300M pps sans perte
  • Latency : <10 µs par packet
  • CPU : 40% (vs 100% avec iptables)

Cas 2 : Zero-trust networking (Netflix)

Problème : Microsegmentation 10,000+ services

Solution : Cilium network policies L3-L7

# Netflix-style policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payment-service-policy
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  
  ingress:
    - fromEndpoints:
      - matchLabels:
          app: api-gateway
      toPorts:
      - ports:
        - port: "8080"
          protocol: TCP
        rules:
          http:
          - method: POST
            path: "/payment/.*"
            headers:
            - "X-Auth-Token: .*"

Résultat :

  • Policies : 10,000+ appliquées
  • Performance : native (eBPF)
  • Compliance : SOC2, PCI-DSS

Cas 3 : Container security (Datadog)

Problème : Détecter runtime attacks

Solution : Falco + Tetragon

Détections :

  • Container escape attempts
  • Privilege escalation
  • Crypto mining
  • Lateral movement

Résultat :

  • Détections : 1,200+ threats/mois
  • False positives : <1%
  • Response time : <5s

Développement eBPF

Outils développement

# Installer dependencies
apt install clang llvm libelf-dev libbpf-dev bpftool

# Cloner libbpf
git clone https://github.com/libbpf/libbpf-bootstrap
cd libbpf-bootstrap/examples/c

Exemple : tracer syscalls

// syscall_tracer.bpf.c
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, u32);
    __type(value, u64);
    __uint(max_entries, 1024);
} syscall_count SEC(".maps");

SEC("tracepoint/raw_syscalls/sys_enter")
int trace_syscall_enter(struct trace_event_raw_sys_enter *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u64 *count = bpf_map_lookup_elem(&syscall_count, &pid);
    
    if (count) {
        __sync_fetch_and_add(count, 1);
    } else {
        u64 init = 1;
        bpf_map_update_elem(&syscall_count, &pid, &init, BPF_ANY);
    }
    
    return 0;
}

char LICENSE[] SEC("license") = "GPL";
// syscall_tracer.c (userspace)
#include <stdio.h>
#include <unistd.h>
#include <bpf/libbpf.h>
#include "syscall_tracer.skel.h"

int main() {
    struct syscall_tracer_bpf *skel;
    
    // Load and verify BPF program
    skel = syscall_tracer_bpf__open_and_load();
    if (!skel) {
        fprintf(stderr, "Failed to load BPF program\n");
        return 1;
    }
    
    // Attach to tracepoint
    if (syscall_tracer_bpf__attach(skel) < 0) {
        fprintf(stderr, "Failed to attach BPF program\n");
        syscall_tracer_bpf__destroy(skel);
        return 1;
    }
    
    printf("Tracing syscalls... Press Ctrl-C to stop\n");
    
    // Poll map every second
    while (1) {
        sleep(1);
        
        u32 pid;
        u64 count;
        int fd = bpf_map__fd(skel->maps.syscall_count);
        
        while (bpf_map_get_next_key(fd, &pid, &pid) == 0) {
            bpf_map_lookup_elem(fd, &pid, &count);
            printf("PID %d: %llu syscalls\n", pid, count);
        }
    }
    
    syscall_tracer_bpf__destroy(skel);
    return 0;
}
# Compiler
clang -O2 -g -target bpf -c syscall_tracer.bpf.c -o syscall_tracer.bpf.o
bpftool gen skeleton syscall_tracer.bpf.o > syscall_tracer.skel.h
gcc -o syscall_tracer syscall_tracer.c -lbpf -lelf -lz

# Exécuter
sudo ./syscall_tracer

Checklist adoption eBPF

Prérequis :

  • Kernel Linux ≥5.15
  • BTF (BPF Type Format) enabled
  • libbpf installé
  • bpftool disponible

Networking :

  • Évaluer Cilium vs CNI actuel
  • Tester kube-proxy replacement
  • Activer Hubble observabilité
  • Configurer network policies L7
  • Benchmark performance

Observabilité :

  • Installer Pixie ou alternative
  • BPFtrace pour debugging
  • Intégrer avec Prometheus
  • Dashboards Grafana
  • Alertes sur métriques eBPF

Sécurité :

  • Déployer Falco runtime security
  • Configurer règles custom
  • Tetragon pour enforcement
  • Intégration SIEM
  • Incident response playbook

Production :

  • Tests charge/performance
  • Rollback plan
  • Documentation équipe
  • Formation équipe ops
  • Monitoring adoption

Conclusion

eBPF révolutionne Linux en permettant observabilité, networking et sécurité haute performance sans modification kernel. L'adoption massive en 2026 (64% Kubernetes avec Cilium) confirme que c'est devenu un standard.

Points clés :

  • eBPF = code kernel safe et performant
  • Cilium = CNI eBPF 10x plus rapide
  • Pixie = observabilité sans instrumentation
  • Falco = runtime security essentielle
  • Performance native sans overhead

Gains typiques :

  • Networking : +20x throughput (XDP)
  • Latency : -80% (kube-proxy → Cilium)
  • Sécurité : détection runtime sans agent
  • Observabilité : 0 instrumentation code
  • CPU : -60% vs iptables

Actions prioritaires :

  1. Tester Cilium dans cluster dev
  2. Installer Pixie pour observabilité
  3. Déployer Falco runtime security
  4. BPFtrace pour debugging
  5. Benchmarker vs solution actuelle
Besoin d'aide sur ce sujet ?

Notre équipe d'experts est là pour vous accompagner dans vos projets.

Contactez-nous

Articles similaires qui pourraient vous intéresser