For tiden får jeg ofte spørgsmålet: “Hvad er det her Cilium og eBPF, folk taler om?” mens jeg står ved kaffemaskinen. Denne tekst er et forsøg på at give et mere struktureret svar, end jeg typisk kan improvisere på fem minutter.
TL;DR–recap
I et Kubernetes-cluster har du brug for en netværkskomponent kaldet Container Network Interface (CNI). CNI leverer netværk og netværkssikkerhed i clustret.
Et specifikt Kubernetes-cluster eller en distribution er IKKE bundet til et bestemt CNI: Forskellige virksomheder bruger forskellige CNIs afhængigt af faktorer som: funktioner, sikkerhed, ydeevne, observability og brugervenlighed for udviklere. Når dit Kubernetes-cluster først er implementeret (medmindre du har en specialdistribution), er det tilladt for alle pods at kommunikere med hinanden. Det kommer fra Kubernetes-netværksmodellen, som siger:
- Pods kan kommunikere med alle andre pods på enhver anden node uden NAT.
- Agents på en node (fx systemdaemons, kubelet) kan kommunikere med alle pods på samme node.
Motivationen for Kubernetes-netværksmodellen er, at udviklere kan fokusere på applikationer og tænke mindre på netværk. Fokusset på udviklerens bekvemmelighed betyder dog, at netværkssikkerhed nogle gange overses. Udfordringen er, at dette nogle gange fører til arkitekturer, hvor netværkssikkerhed primært fokuseres på cluster perimeter (”hard shell, soft core”).
Cilium er et moderne CNI, der tilbyder avanceret netværkssikkerhed, høj performance og er let at bruge. Det gør, at Cilium er et stærkt supplement til at give dine Kubernetes-clustre bedre sikkerhed og observability i stedet for at være den sorte boks ”i hjørnet af netværket”. Cilium er relativt nyt, men har allerede opnået bred udbredelse og er et foretrukket valg hos mange store virksomheder. Så hvordan opnår Cilium sine brede funktionalitet, samtidig med at det stadig yder godt? Cilium bruger en underliggende Linux-funktion kaldet eBPF, som fungerer som en virtuel maskine (VM) i Linux-kernen. Det giver dig mulighed for at indsætte probe points i kernen, opfange pakker, sende dem til små programmer og derefter beslutte, hvad der skal gøres med dem.
Hvis dette svarer på dine spørgsmål, kan du stoppe med at læse nu 😊
Men selvfølgelig er historien længere. Cilium sigter mod at gøre meget mere end tidligere Kubernetes CNIs. Virksomheden bag Cilium, Isovalent, blev for nylig opkøbt af Cisco, og de har store planer. Udover netværk giver eBPF udviklere mulighed for at injicere kode i kernen, hvilket muliggør ændringer i realtid i stedet for at vente uger på kernel-opdateringer. Det åbner en verden af muligheder.
Lad mig uddybe…
Hvad er eBPF?
Den oprindelige Berkeley Packet Filter (BPF) blev udgivet i 1993 og var designet som en netværkstap og pakkefilter til Unix. Mange netværks- og Linux-entusiaster vil kunne genkende en af dens mest berømte anvendelser: tcpdump.
eBPF er efterfølgeren til BPF, hvor “e” oprindeligt betød “extended”. Det udvider BPF’s kapaciteter betydeligt og muliggør anvendelser inden for områder som sikkerhed, tracing og observability. Kort sagt gør eBPF Linux-kernen programmerbar(!). eBPF er open-source og har støtte fra store organisationer som Meta, Google, Microsoft, Netflix… og naturligvis Isovalent. Facebook (Meta) var tidligt ude og brugte eBPF til datacenter-tracing og deres højtydende load balancer, Katran.
Hvordan fungerer eBPF?
eBPF fungerer ved at køre små programmer inde i Linux-kernen. Det fungerer som en sandboxed virtuel maskine i kernen, der tilslutter sig specifikke kerneevents, såsom system calls, netværks events eller process starts. Denne funktionalitet giver en kraftfuld og fleksibel måde at håndtere pakker og kernehændelser i realtid – og giver mulighed for at opdatere kernen under drift. Et eksempel på eBPF i aktion er Cilium, som bruger eBPF til at levere avancerede netværksfunktioner.
En kort kronologisk historie om eBPF
1993: Introduktion af den oprindelige Berkeley Packet Filter (BPF) til netværkspakkefiltrering i Unix-lignende operativsystemer
2012: Seccomp-BPF introduceret, en sikkerhedsanvendelse (ikke-netværksrelateret), der tillader system call filtrering ved hjælp af BPF
2014: eBPF introduceret
2016: Introduktion af XDP (eXpress Data Path) til højtydende pakkebehandling ved hjælp af eBPF
2017: Cilium-projektet lanceret. Udnytter eBPF til netværk og sikkerhed i Kubernetes
2018: Facebooks Katran load balancer, der bruger eBPF, open-sourced
2019: eBPF support udvidet til Windows af Microsoft (første stadier, ikke native)
2021: eBPF Foundation etableret for at fremme eBPF-udvikling og –adoption.
Passer godt til mikroservice-filosofien
I moderne arkitekturer designer vi applikationer til at fungere uafhængigt af hinanden, hvilket er, hvor containere og pods kommer ind i billedet. Men hvad nu, hvis vi ønsker fælles funktionalitet på tværs af containere? I stedet for at bygge dette ind i hver pod, kan eBPF levere en mere effektiv løsning på kernel-niveau.
Hvis du er nysgerrig på eBPF’s historie, kan jeg anbefale den 30-minutter lange dokumentar “eBPF: Unlocking the Kernel”.
Kubernetes-netværk & CNI
Som nævnt i introduktionen bruger forskellige virksomheder forskellige CNIs afhængigt af ting som funktioner, sikkerhed, ydeevne og observability. Ofte er valget af CNI relateret til den underliggende infrastruktur. Hvis dit cluster fx er implementeret i AWS, vil du sandsynligvis bruge standard Amazon VPC CNI, der, som navnet antyder, integrerer sig nemt med andre AWS-tjenester.På grund af denne valgfrihed findes der flere CNIs.
Set fra Kubernetes-clusterets perspektiv er kravene til en CNI ikke strenge; En CNI skal kunne understøtte netværk og overholde Kubernetes-netværksmodellen. Kubernetes har en NetworkPolicy-struktur, som giver mulighed for L3/L4-trafikstyring, men… ikke alle CNIs understøtter NetworkPolicy-strukturen (de behøver det ikke), og nogle gange ønsker man mere avancerede funktioner. Dette landskab fører undertiden til implementeringer, hvor netværkssikkerhed kun anvendes på clustrets kant (ingen øst-vest-filtrering), eller til en simpel politik, hvor cluster-namespaces er adskilt, men alt inden for det enkelte namespace er tilladt.
En CNI, der er blevet rost for sine sikkerhedsfunktioner, er Calico, og den er ofte blevet brugt som “opgradering” til den standard cloud-leverandør CNI, når mere avancerede funktioner er nødvendige. For at gå endnu længere understøtter Calico både Kubernetes network policies og sine egne Calico network policies.
En anden trend i Kubernetes er service mesh; Service mesh tilbyder funktioner som load balancing, service discovery, sikkerhed og håndtering af TLS-kryptering mellem alle pods. Det smarte er, at alt dette gøres uden at ændre applikationskoden i pods, så udvikleren ikke behøver at bekymre sig om netværksløsningen. Det gøres ved at injicere en sidecar-container sammen med applikationscontaineren i hver pod, som fungerer som en netværksproxy. Dog kan service meshes tilføje kompleksitet, overhead og øget ressourceforbrug (du fordobler antallet af containere i dit cluster).
Ind på scenen: Cilium
Cilium tilbyder det bedste fra begge verdener: Det fungerer både som en CNI og dækker 90% af, hvad en service mesh gør. Ved at bruge eBPF til dyb kernel-integration forbedrer Cilium sikkerhed og ydeevne ud over traditionelle CNIs. En af Ciliums nøglefordele er, at det forbedrer Kubernetes’ native kube-proxy (kube-proxy er ansvarlig for netværksforbindelser mellem services og pods). I stedet for at bruge iptables, som kan blive komplekst og ressourcekrævende, optimerer Cilium trafikstyringen ved hjælp af eBPF.
Cilium er nemt at programmere og kan håndteres af udviklere, i modsætning til eBPF, som kræver en dyb forståelse af Linux-kernen. Dette passer godt ind i platform engineering-praksis, hvor et team får en platform og er ansvarlige for komponenterne inden for platformen: Hvilke komponenter kan kommunikere med hvilke, osv.
Ved at udnytte kapabiliteterne i eBPF kan Cilium så gøre mere, end hvad der normalt forventes af en CNI? Svaret er ja, og Cilium tilføjer kontinuerligt nye funktioner. Et eksempel er, at udover L3/L4 NetworkPolicy understøtter Cilium L7-filtrering. Andre eksempler på Ciliums funktioner inkluderer Kubernetes ingress og egress gateway, host firewall, kryptering mellem noder, multi-cluster-forbindelse + sikkerhed, BGP, multicast, IPv6-understøttelse og mere.
Virksomheden bag Cilium, Isovalent, har udviklet andre produkter i Cilium-familien:
- Hubble: Tilbyder synlighed og fejlfinding i Cilium-baserede netværk. Det kan tilgås via CLI eller en GUI.
- Tetragon: Tilføjer sikkerhedsobservability og runtime enforcement, hvilket udvider Ciliums kapaciteter inden for sikkerhed.
Udover Cilium
eBPF er et meget kraftfuldt værktøj, når man arbejder med container-sikkerhed, og der er andre løsninger derude ud over Cilium, der udnytter eBPF og Seccomp-BPF.
Hvis du har arbejdet med container-sikkerhed, er du sandsynligvis stødt på Falco, som udnytter eBPF. Andre bemærkelsesværdige værktøjer som AppArmor og gVisor bruger Seccomp-BPF til systemkaldsfiltrering.
Leg med Cilium
Er du nysgerrig på Cilium, og vil du gerne have fingrene i det?
Det er ikke svært. De store cloud-leverandører understøtter Cilium og har dokumentation til, hvordan man installerer det.
Eller foretrækker du at lave noget på din egen laptop? Dette er også nemt — fx ved hjælp af minikube: Du kan installere et mini-cluster uden CNI og derefter blot tilføje Cilium.
Vil du gerne have nogle lab-øvelser, der illustrerer dette? Jeg kan anbefale lab-øvelserne på isovalent.com, hvor jeg selv har brugt tid.
Hvad er på horisonten?
Godt spørgsmål.
Jeg var til KubeCon + CloudNativeCon Europe 2024 i Paris i marts i år, og der var meget snak om og interesse i Cilium. Isovalent har udtalt en strategi om at forbinde ikke-Kubernetes-miljøer med Kubernetes via Cilium Mesh, samtidig med at funktionaliteten i Kubernetes fortsat udvides. Eller for at citere Isovalent fra scenen på KubeCon: “Bring Cilium’s Security, Scale, and Simplicity to the rest of the industry and keep Kubernetes as the center of gravity.” Lad os se, hvor det går hen, mens de kigger på host- og edge-noder.
Derudover blev Isovalent for nylig opkøbt af Cisco (opkøbet blev afsluttet i april 2024), og der er ambitiøse planer for fremtiden. Hvis du vil vide mere om Cisco Hypershield-retningen eller få perspektivet fra en sikkerhedsekspert, der er mindre Kubernetes-centreret end mig, kan jeg anbefale min kollegas blogindlæg: “Cisco Hypershield: Velkommen til en ny æra!”
Der er også meget momentum i eBPF-lejren. Bag udsagnet “eBPF er på vej til Windows” ligger målet om at sikre, at eksisterende eBPF-baserede værktøjer er kompatible. eBPF-bytecode-sproget og begreber som verifikation og just-in-time-kompilering vil være de samme, mens de faktiske hook points, hvor eBPF-programmer kan tilslutte sig, vil variere afhængigt af operativsystemet.
Der er planer om at optimere eBPF til at forstå trafik til GPU’er og DPU’er og GPU’er, og DPU’er er relevante i forbindelse med den stigende efterspørgsel efter AI og ML.
En anden plan er at bruge eBPF til at muliggøre distribueret intelligens med målet om at bringe behandling tættere på datakilden, så man kun streamer de behandlede data eller reagerer på data i realtid.
Referencer
• eBPF-dokumentation: What is eBPF?
• Wikipedia-artikel: eBPF
• Kubernetes-dokumentation: The Kubernetes network model
• Isovalent blog: What is Kube-Proxy and why move from iptables to eBPF?
• cilium.io/blog: eBPF – The Future of Networking & Security
• Dokumentar om eBPF og Ciliums historie: eBPF: Unlocking the Kernel [OFFICIAL DOCUMENTARY]
• eBPF Summit 2024: the virtual event for all things within the Open Source eBPF ecosystem – recording
• Blogindlæg om Cisco Hypershield: Cisco Hypershield: Velkommen til en ny æra!
• Blogindlæg om container-sikkerhed: Unlocking Kubernetes-sikkerhed: Indsigt, løsninger og innovationer