Dalla sicurezza perimetrale alla Software-Defined Network. Zero-Trust e Observability con Cilium ed eBPF

1. L'Evoluzione della Sicurezza e del Networking

 

1.1. Software-Defined Network in Ambienti Kubernetes

Il passaggio ad architetture a micro-servizi cloud native ha reso i tradizionali approcci alla sicurezza perimetrale obsoleti. Nelle infrastrutture legacy, la sicurezza si basava principalmente su firewall L3/L4 posizionati fisicamente ai confini della rete. In un ecosistema Kubernetes, i workload sono effimeri, dinamici e distribuiti: un pod può nascere e morire in pochi secondi, cambiando costantemente indirizzo IP. L'approccio statico basato su IP diventa quindi inefficiente e impossibile da scalare. La Software-Defined Network (SDN) supera questo limite disaccoppiando l'infrastruttura logica da quella fisica: la rete diventa programmabile e le policy di micro-segmentazione vengono ancorate alle identità crittografiche (o label) dei pod, garantendo un'architettura molto più resiliente e intrinsecamente sicura.

 

1.2. Panoramica e Concetti su eBPF

Alla base delle reti SDN di nuova generazione vi è eBPF (Extended Berkeley Packet Filter). Questa tecnologia rivoluzionaria permette di eseguire programmi sandbox altamente ottimizzati direttamente all'interno dello spazio del kernel Linux, senza dover modificare il codice sorgente del kernel stesso o caricare moduli aggiuntivi. Nel contesto del networking, eBPF si aggancia a punti di intercettazione strategici (come XDP - eXpress Data Path e TC - Traffic Control) permettendo di bypassare il tradizionale, e più lento, stack di rete di Linux (come iptables e netfilter). Il risultato è un filtraggio e un instradamento dei pacchetti con prestazioni eccezionali (spesso a velocità di linea hardware) e un overhead minimo sulla CPU.4

 

1.3. Cilium: il Networking Zero-Trust per il Cloud Native

Cilium è la piattaforma open-source che sfrutta appieno la potenza di eBPF per fornire networking, sicurezza e osservabilità nativa all'interno di Kubernetes. Sostituendo la gestione della rete basata su kube-proxy, Cilium si integra come Container Network Interface (CNI) ed è in grado di operare a tutti i livelli del modello OSI, fino al Layer 7 (applicativo). Quando è richiesta un'ispezione avanzata del traffico (es. chiamate HTTP, gRPC o Kafka), Cilium dirotta in modo trasparente i pacchetti dal kernel eBPF verso un proxy Envoy integrato. Questo modello ibrido kernel/userspace permette l'implementazione nativa di architetture Zero-Trust, garantendo comunicazioni cifrate tra i pod (mTLS) e l'applicazione di policy di sicurezza granulari senza impattare sulle performance.

 

2. Case Study: Trasformazione in un Cliente di Servizi Digitali

Questo case study esamina il percorso di adozione tecnologica di un importante cliente che fornisce servizi digitali per il settore pubblico e privato. L'obiettivo era modernizzare l'infrastruttura di rete dei propri cluster Kubernetes, superando i colli di bottiglia dei load balancer tradizionali e ottenendo visibilità totale sul traffico applicativo.

2.1. Architettura e Implementazione: Gateway API e L2 Announcement

Con l’allestimento dei nuovi ambienti Kubernetes è stato introdotto Cilium per sostituire le precedenti soluzioni di networking, concentrandosi su due innovazioni architetturali fondamentali. Vediamole brevemente.

• Adozione delle Gateway API - Il cliente ha deciso di superare i classici Ingress Controller adottando il nuovo standard Kubernetes Gateway API, supportato nativamente da Cilium. Dal punto di vista tecnico, questo standard disaccoppia la definizione dell'infrastruttura (il Gateway gestito dagli admin) dalle regole di instradamento (le HTTPRoute gestite dagli sviluppatori). Cilium traduce queste risorse direttamente in configurazioni eBPF ed Envoy, gestendo il traffico in ingresso (North-South) in modo più espressivo, ad esempio permettendo routing avanzato basato su header HTTP, path e pesi per rilasci Canary, il tutto senza dispiegare proxy esterni dedicati.

 

• Node Balancing L2 (L2 Announcement) - Negli ambienti on-premise, l'esposizione dei servizi verso l'esterno richiede tipicamente un Load Balancer software (come MetalLB) o appliance hardware costose. Con Cilium, il cliente ha sfruttato la funzionalità nativa di L2 Announcement. A livello tecnico, Cilium utilizza un meccanismo di Leader Election tramite i Lease di Kubernetes per assegnare la proprietà di un Virtual IP (VIP) a un nodo specifico. Il demone Cilium su quel nodo risponde alle richieste ARP (IPv4) o NDP (IPv6) sulla rete locale (Layer 2). In caso di caduta del nodo, un nuovo leader viene eletto istantaneamente e invia messaggi Gratuitous ARP per aggiornare gli switch di rete. Questo ha permesso di avere bilanciamento ad alta affidabilità senza aggiungere componenti aggiuntivi al cluster, pur mantenendo compatibilità in parallelo con bilanciatori esterni VMware preesistenti.

 

2.2 Network Observability e Next-Generation Firewall Integrato (L7)

Il vero punto di svolta del progetto è stato l'attivazione di Hubble, il framework di osservabilità nativo di Cilium. Poiché eBPF "vede" ogni singolo pacchetto che attraversa il kernel, Hubble raccoglie questi dati telemetrici direttamente dai ring buffer di eBPF, fornendo al cliente una mappa topologica in tempo reale delle comunicazioni (Service Map), completa di metriche su latenza, drop dei pacchetti e codici di stato HTTP.
Questa visibilità ha reso possibile un'implementazione sicura e misurata delle CiliumNetworkPolicies (CNP). Mentre i firewall tradizionali (L3/L4) e le standard NetworkPolicy di Kubernetes filtrano solo per range IP, le CNP operano a livello applicativo (L7). Il cliente ha potuto implementare regole restrittive basate su Hostname (FQDN) esterni (es. consentire il traffico solo verso api.github.com o vcenter.local). Tecnicamente, Cilium intercetta le query DNS in uscita dai pod (DNS Proxy), memorizza in cache gli IP restituiti per quel dominio e applica dinamicamente le regole di firewalling eBPF solo per quegli indirizzi e per il Time-To-Live (TTL) del DNS.

Questa capacità ha trasformato l'infrastruttura di rete in un Next-Generation Firewall distribuito. Il cliente ha potuto rimuovere i proxy HTTP esterni precedentemente utilizzati per filtrare il traffico in uscita, abbattendo la latenza e rimuovendo un critico Single Point of Failure (SPOF).

 

2.3 Roadmap Evolutiva: Service Mesh, Egress Gateway e Tetragon

A valle di questo successo, la roadmap architetturale del cliente punta verso un'infrastruttura ancora più scalabile.

• Cilium Cluster Mesh - L'interconnessione di più cluster Kubernetes indipendenti. I pod in cluster differenti potranno comunicare direttamente (Est-Ovest) come se fossero nella stessa rete, mantenendo crittografia mTLS nativa e applicazione coerente delle policy di sicurezza, senza i colli di bottiglia dei gateway VPN tradizionali.
• Cilium Egress Gateway - Per integrare il traffico Kubernetes con i rigidi firewall perimetrali fisici del data center, verrà implementato l'Egress Gateway. Questa funzione eBPF implementerà il masquering del traffico in uscita da specifici namespace o pod, facendolo uscire dal cluster con indirizzi IP sorgente statici e predicibili. In questo modo, i firewall legacy esterni potranno identificare e filtrare il traffico proveniente dai microservizi in modo affidabile.
• Runtime Security con Tetragon - Oltre al networking, il cliente valuterà l'uso di Tetragon, agente eBPF che fornisce sicurezza a livello di esecuzione (Runtime). Tetragon intercetta chiamate di sistema (syscalls) direttamente nel kernel, potendo bloccare in tempo reale esecuzioni di processi anomali, tentativi di privilege escalation o accessi a file sensibili, completando a 360 gradi la postura Zero-Trust.