NetObserv

​

​

Observabilité réseau

et eBPF

∘

Joël Takvorian

Qui suis-je?

• Développeur chez Red Hat depuis 2016
• Hawkular, Vert.x metrics, Kiali

​

• Ex dev C++, ex-Java… désormais principalement Go
• Et TypeScript, et un peu de C

​

• En 2021 j’ai la chance de monter une petite équipe pour créer NetObserv

https://dev.to/jotak

​

@jotak@framapiaf.org

​

​

NetObserv en bref

• Observabilité réseau taillée pour k8s/OpenShift

​

• Flux réseau L2/3/4 (MAC, IP, TCP, …) enrichis

​

• Basé sur eBPF

​

• Open-source (Apache v2)

​

• A.k.a “Network Observability” dans OpenShift.

https://netobserv.io/

​

https://github.com/netobserv/

​

@netobserv@hachyderm.io

​

@netobserv.bsky.social

NetObserv démo

si les dieux du Wifi le veulent

🪄

Mais encore ?

Une vue Topologie

• Avec différents niveaux d'agrégation (node, namespaces, pods…)

​

• Entièrement filtrable

Mais encore ?

Une vue détaillée

• Tous les flows, rien que les flows
• Enrichis (k8s, latence, DNS, drops, AZ, …)
• Toujours entièrement filtrable

Mais encore ?

Plein

​

de

​

stats.

NetObserv & eBPF

Composants NetObserv

• Des agents eBPF
• Écoutent le réseau, corrèlent et enrichissent, constituent des flows, exportent
• Flowlogs-pipeline
• Collecte et enrichit pour Kubernetes, génère des métriques, exporte
• Un plugin de visualisation
• Permet de naviguer dans ces données
• Intégré à OpenShift, ou console standalone (brute de fonderie)
• Un opérateur Kubernetes
• Orchestre tout ce petit monde et fournit 2 APIs (FlowCollector et FlowMetrics)
• Une CLI
• Debug à la demande ; packet capture
• Indépendante de l’opérateur

Architecture NetObserv

eBPF vous dîtes?

L’idée de base : injecter dans le kernel un programme depuis l’espace utilisateur*, au runtime, de façon sûre.

​

*sans devoir le recompiler à chaque màj du noyau

Comment ça marche?

Historique rapide

• BPF = vieille techno des 90’ pour *NIX
• Berkeley/BSD Packet Filter
• Ex : tcpdump…
• 2013, refonte totale, naissance d’eBPF
• Par Alexei Starovoitov (PLUMGrid, Facebook…) et Daniel Borkmann (Red Hat, Cilium…)
• Plus versatile
• Fréquentes améliorations depuis lors
• Maps, uprobes, XDP, etc.
• Les promesses : sécurité et performances

Cas d’usage: observation

Exemple de code

Exemple de code

Exemple de code

// Attributes that uniquely identify a flow

typedef struct flow_id_t {

u8 src_ip[IP_MAX_LEN];

u8 dst_ip[IP_MAX_LEN];

u16 src_port;

u16 dst_port;

u8 transport_protocol;

} flow_id;

// Key: the flow identifier. Value: the flow metrics.

struct {

__uint(type, BPF_MAP_TYPE_HASH);

__type(key, flow_id);

__type(value, flow_metrics);

__uint(max_entries, 1 << 24);

__uint(map_flags, BPF_F_NO_PREALLOC);

__uint(pinning, LIBBPF_PIN_BY_NAME);

} flows_map SEC(".maps");

//go:generate bpf2go -cc clang -cflags $BPF_CFLAGS -target amd64,arm64 -type flow_metrics_t -type flow_id_t Bpf ../bpf/flows.c -- -I../bpf/headers

Exemple de code

SEC("classifier/tcx_ingress")

int tcx_ingress_flow_parse(struct __sk_buff *skb) {

flow_id id;

__builtin_memset(&id, 0, sizeof(id));

​

if (fill_ethhdr(&id, skb->data, skb->data_end)) {

u64 time = bpf_ktime_get_ns();

flow_metrics *metrics = (flow_metrics*) bpf_map_lookup_elem(&flow_map, &id);

if (metrics == NULL) {

flow_metrics new_metrics = {

.packets = 1,

.bytes = skb->len,

.start_mono_time_ts = time,

.end_mono_time_ts = time,

};

bpf_map_update_elem(&flow_map, &id, &new_metrics, BPF_NOEXIST);

} else {

metrics->packets += 1;

metrics->bytes += skb->len;

metrics->end_mono_time_ts = time;

}

}

return TCX_NEXT;

}

Verifier & limitations

On ne fait pas tout ce qu’on veut! (mais c’est pour la bonne cause)

• Complexité limitée: 4096 1 million d’instructions
• Boucles infinies / à taille variable interdites
• Concurrence: contraintes sur les locks
• (etc.)

​

NetObserv & eBPF

Que fait NetObserv d’autre avec eBPF?

• sRTT / latency
• Récupéré de `sock->srtt_us`
• DNS
• Lecture headers DNS en clair, extraction code d’erreur, calcul latence
• Drops noyau
• Cause du drop exposée via la fonction `kfree_skb`
• Suivi du NAT
• Possible grâce au hook `nf_nat_manip_pkt`
• Packet capture
• Même TC hook, mais envoie tout sur un perf-buffer

NetObserv & eBPF

Que fait NetObserv d’autre avec eBPF?

• Suivi de “Network Events”
• Pour l’instant, implémentation spécifique d’OpenVSwitch (OVS)
• Hook `rh_psample_sample_packet`
• Ex: dropped/accepted by Network Policy

​

​

• (User defined networks observability - tech preview)

Futur-NetObserv & eBPF

Que pourrait-on faire d’autre avec eBPF?

• Reconnaître plus de protocoles
• Ex: Proxy protocol
• Détection IPSEC et TLS
• Zero-trust networking: tout est-il réellement chiffré?
• Quelle version de TLS est utilisée?
• Uprobe OpenSSL
• Lire les headers HTTP
• Fournir des statistiques sur les codes d’erreur
• Fournir des statistiques sur les URL invoquées
• Calculer les temps de réponse
• Espionner

Risques et sécurité

• Grands pouvoirs, grandes responsabilités
• Privileged=true …

​

​

• … ou CAP_BPF, CAP_PERFMON,

CAP_NET_ADMIN, CAP_SYS_RESOURCE

​

Risques et sécurité

Non, installer un programme eBPF n’est pas anodin

• Surface d’attaque ↗ pour un attaquant
• Vrai pour NetObserv comme pour les autres
• C’est un contrat de confiance avec l’éditeur
• (Privilégiez l’open-source?)
• Cependant, le verifier eBPF blinde la sécurité, et le runtime est sandboxé
• pas de kernel panic
• pas de buffer overflow
• pas de lecture mémoire arbitraire
• etc.
• Pas pire que des modules noyau, bien au contraire!

Risques et sécurité

Risques et sécurité

1 mois avant la fameuse panne Windows, une panne étonnamment similaire touchait… Red Hat

… via eBPF

https://www.theregister.com/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

Risques et sécurité

bpfman

​

“An eBPF Manager”, sandbox CNCF (Tech preview dans OpenShift)

• Évite les conflits entre programmes eBPF
• Simplifie une partie de l’écriture du code (chargement / déchargement)
• Meilleure visibilité des programmes eBPF chargés
• Résoud (ou limite) le problème de surface d’attaque via les privilèges accordés

Q

A

&

&

MERCI!