Was das Cilium-Upgrade im Cluster kappen kann
Cilium 1.19 bringt einen optionalen Strict-Mode für Node-Verschlüsselung und ändert Netzwerk-Defaults. Was Cloud-Teams vor dem Upgrade prüfen müssen.
6 Min. Lesezeit
Cilium 1.19 führt einen optionalen Strict-Mode für die Verschlüsselung zwischen Cluster-Nodes ein. Wer ihn aktiviert, ohne die Konfiguration zu prüfen, riskiert, dass unverschlüsselter Datenverkehr stillschweigend verworfen wird. Zehn Jahre nach dem Start liefert Cilium ein Release, das vor allem die Sicherheit härtet.
Das Wichtigste in Kürze
- Strict-Mode verwirft Unverschlüsseltes: Der neue, optionale Strict-Mode für IPsec und WireGuard verwirft unverschlüsselten Datenverkehr zwischen Nodes. Eine Fehlkonfiguration legt die Kommunikation im Cluster lahm.
- Der Policy-Default ändert sich: Netzwerk-Policies ohne explizite Cluster-Angabe erlauben jetzt nur noch den lokalen Cluster. Multi-Cluster-Setups brauchen vor dem Upgrade einen Policy-Review.
- Der Kernel muss mitspielen: eBPF Host Routing läuft automatisch, setzt aber einen Node-Kernel mit dem Fix für CVE-2025-37959 voraus.
Verwandt:Platform Engineering: Wofür eine Internal Developer Platform steht / VMware Cloud Foundation 9.1
Was Cilium 1.19 unter der Haube ändert
Was ist Cilium 1.19? Die aktuelle Hauptversion des eBPF-basierten Netzwerk- und Sicherheits-Layers für Kubernetes. Statt eines einzelnen Leuchtturm-Features härtet sie Verschlüsselung, Netzwerk-Policies und Skalierbarkeit. Der aktuelle stabile Stand ist 1.19.5.
Cilium sitzt als Datenpfad zwischen den Pods und ersetzt in vielen Pfaden kube-proxy und iptables-Regeln durch eBPF-Programme, die direkt im Linux-Kernel laufen. Diese Position macht jedes Release sicherheitsrelevant: Was sich am Datenpfad ändert, betrifft jeden Service im Cluster.
Zum zehnjährigen Bestehen gibt es kein Schaufenster-Feature. Der Schwerpunkt liegt auf Verschlüsselung, klareren Policy-Regeln und Skalierbarkeit für große Cluster. Genau diese Art von Release ist im Betrieb heikel, weil die Änderungen tief und unauffällig sind.
Der neue Strict-Mode für die Verschlüsselung
Die wichtigste Änderung betrifft die Verschlüsselung zwischen Nodes. Cilium 1.19 führt einen optionalen Strict-Mode für IPsec und WireGuard ein. Bislang war die Node-zu-Node-Verschlüsselung best-effort: Was sich verschlüsseln ließ, wurde verschlüsselt, der Rest lief im Klartext weiter.
Im Strict-Mode kippt diese Logik. Unverschlüsselter Datenverkehr zwischen Nodes wird verworfen. Das ist sicherheitstechnisch sauber, im Betrieb aber eine Falle. Wer den Modus aktiviert, während ein Teil der Nodes die Verschlüsselung noch nicht korrekt aushandelt, kappt die Verbindung zwischen ihnen.
Die Empfehlung für die Praxis: erst in einer Staging-Umgebung aktivieren, den Node-zu-Node-Verkehr beobachten und sicherstellen, dass alle Nodes die Schlüssel sauber austauschen. Erst danach in Produktion. Ein blinder Strict-Switch ist der schnellste Weg zu einem Ausfall, der sich schwer diagnostizieren lässt.
Der Policy-Default, der Multi-Cluster trifft
Die zweite stille Änderung steckt in den Netzwerk-Policies. Bisher konnte ein Selektor ohne explizite Cluster-Angabe Kommunikation über Cluster-Grenzen hinweg erlauben. Ab 1.19 gilt als Default nur noch der lokale Cluster.
Für ein einzelnes Cluster ändert sich nichts. Wer aber Cluster Mesh betreibt und Policies hat, die auf Dienste in anderen Clustern zielen, muss diese Regeln explizit machen. Sonst greifen sie nach dem Upgrade nur lokal und Cross-Cluster-Verbindungen fallen aus.
Daneben gibt es kleinere, praktische Erweiterungen. Host-Firewall-Regeln können jetzt die Protokolle VRRP und IGMP matchen. Und wenn eine Policy eine Verbindung ablehnt, kann Cilium eine ICMPv4-Meldung zurückgeben, statt das Paket kommentarlos zu verwerfen. Das erleichtert die Fehlersuche spürbar.
| Bereich | Vor 1.19 | Ab 1.19 |
|---|---|---|
| Node-Verschlüsselung | best-effort, Rest im Klartext | Strict-Mode verwirft Unverschlüsseltes |
| Policy ohne Cluster-Angabe | cluster-übergreifend möglich | nur lokaler Cluster |
| Multi-Pool IPAM | Beta | stabil |
| Workload-Verschlüsselung | Sidecar-Proxy nötig | Ztunnel-Beta ohne Sidecar |
Ztunnel und Multi-Pool IPAM
Zwei weitere Punkte sind für Plattform-Teams relevant. Cilium 1.19 bringt eine Beta-Integration von Ztunnel. Damit lassen sich TCP-Verbindungen zwischen Workloads transparent verschlüsseln und authentifizieren, ohne dass jeder Pod einen Sidecar-Proxy braucht. Für Teams, die ein Service Mesh ohne den Sidecar-Overhead suchen, ist das ein Pfad, der sich jetzt testen lässt.
Außerdem ist Multi-Pool IPAM jetzt stabil. Über den Helm-Wert ipam.mode=multi-pool lassen sich verschiedene IP-Pools definieren und ein Pod-Selektor wählt den passenden Pool anhand von Labels, ohne dass die Pod-Spezifikation geändert werden muss. Das hilft überall dort, wo IP-Bereiche nach Team oder Umgebung getrennt werden müssen.
Was vor dem Upgrade auf die Checkliste gehört
Cilium 1.19 ist kein Klick-und-fertig-Upgrade. Drei Punkte entscheiden, ob es sauber läuft.
- Kernel prüfen: eBPF Host Routing wird automatisch aktiviert und verlangt einen Node-Kernel mit dem Fix für CVE-2025-37959. Ohne den passenden Kernel scheitert das Upgrade.
- Strict-Mode stufenweise: Verschlüsselung erst in Staging auf strict setzen, Node-Verkehr beobachten, dann Produktion. Nie als Big-Bang.
- Policies sichten: Bei Cluster Mesh alle Netzwerk-Policies ohne explizite Cluster-Angabe identifizieren und anpassen, bevor der lokale Default greift.
Diese drei Punkte gehören vor das Upgrade. Wird einer übersprungen, verlagert sich die Fehlersuche in den laufenden Cluster, wo sie deutlich teurer ist.
Häufige Fragen
Was ist neu an der Verschlüsselung in Cilium 1.19?
Cilium 1.19 führt einen optionalen Strict-Mode für IPsec und WireGuard ein. Wird er aktiviert, verwirft er unverschlüsselten Datenverkehr zwischen Nodes, statt ihn wie bisher im Klartext durchzulassen. Das erhöht die Sicherheit, verlangt aber, dass alle Nodes die Schlüssel korrekt aushandeln.
Warum kann das Upgrade Multi-Cluster-Setups treffen?
Netzwerk-Policies ohne explizite Cluster-Angabe erlauben ab 1.19 nur noch den lokalen Cluster. Wer Cluster Mesh nutzt und Regeln hat, die auf Dienste in anderen Clustern zielen, muss diese explizit machen. Sonst greifen die Policies nach dem Upgrade nur lokal.
Welche Kernel-Voraussetzung gibt es?
eBPF Host Routing wird in 1.19 automatisch aktiviert und setzt einen Node-Kernel voraus, der den Fix für CVE-2025-37959 enthält. Vor dem Upgrade sollte der Kernel-Stand aller Nodes geprüft werden.
Was bringt die Ztunnel-Integration?
Die Ztunnel-Beta verschlüsselt und authentifiziert TCP-Verbindungen zwischen Workloads transparent, ohne dass jeder Pod einen Sidecar-Proxy braucht. Sie ist ein Weg zu einem Service Mesh mit weniger Overhead und lässt sich in 1.19 als Beta testen.
Lohnt sich das Upgrade auf 1.19?
Für sicherheitsbewusste Cluster ja, weil Verschlüsselung und Policy-Verhalten klarer werden. Der Aufwand liegt in der Vorbereitung: Kernel-Stand, stufenweiser Strict-Mode und ein Policy-Review bei Multi-Cluster entscheiden über einen reibungslosen Übergang.
Lesetipps der Redaktion
cloudmagazinPlattform oder Fassade? Platform Engineering ehrlich betrachtetcloudmagazinWarum Backstage den IDP-Markt fast allein beherrschtcloudmagazinCloud-Souveränität in der Praxis: C5, Datenresidenz, SchlüsselhoheitMehr aus dem MBF Media Netzwerk
MyBusinessFuturePredictive Analytics im ERP: Wie Mittelstands-Tech-Teams Kundenbindung 2026 messbar machenDigital ChiefsSmart Factory: Warum Edge am Prozess hängtSecurityTodayGeteilter Kernel als Lücke: Wie Container-Ausbrüche gelingenBildquelle: KI-generiert (Juli 2026)
Auch verfügbar in
