Wenn das CVE kommt, ist es zu spät

Istio macht alle drei Monate ein Minor Release. Patches kommen häufiger, oft ohne großen Aufwand. Klingt planbar.

In der Realität sehe ich regelmäßig Setups, die seit 18 Monaten auf derselben Minor-Version stehen. Begründung: “Ein Update ist zu riskant, das machen wir, wenn wir Zeit haben.”

Die Zeit kommt nicht. Sie wird genommen, meistens dann, wenn sie keiner mehr hat.

Der typische Ablauf:

Ein kritisches CVE wird veröffentlicht. Patch verfügbar, aber nur für die letzten zwei Minor-Versionen. Das eigene Setup hängt fünf Releases hinterher. Plötzlich ist nicht mehr “Update wann es passt” das Thema, sondern “Update bis Freitag, sonst ist die Compliance-Abteilung im Haus”.

Was vorher als kontrolliertes Risiko gerechtfertigt wurde, ist innerhalb von 24 Stunden zur ungeplanten Notfall-Migration über fünf Versions-Sprünge geworden. Mit allem, was dazugehört: Breaking Changes, die niemand getestet hat. API-Deprecations, die in der Zwischenzeit passiert sind. Verhaltensänderungen im Production-Traffic, die in keinem Changelog auftauchen.

Patches sind meistens stressfrei. Aber wenn ein CVE kommt, brennt die Hütte und keiner hat einen Eimer parat.

Das ist kein Istio-Problem. Es ist ein Lifecycle-Problem.

Was in den meisten Setups fehlt:

Ein etablierter Prozess für Quarterly Updates, der nicht jedes Mal neu erfunden wird. Eine Parallelinstallation oder Canary-Cluster, gegen den Entwickler-Teams ihre Services testen können, bevor das Update produktiv geht. Ein klares Verständnis, welche eigenen Konfigurationen und CRDs zwischen Versionen kompatibel bleiben und welche nicht.

Stattdessen sehe ich oft: Updates werden behandelt wie ein Projekt, das jedes Quartal von vorne anfängt. Diskussion, Risikobewertung, Verschiebung, irgendwann Frust, dann doch nicht. Das funktioniert genau so lange, bis es nicht mehr funktioniert.

Wer Istio in Production betreibt, hat ein Quarterly-Lifecycle-Problem. Ob er das wahrhaben will oder nicht. Updates braucht jeder. Die Frage ist, ob euer Prozess auch dann trägt, wenn ein CVE plötzlich keine Wahl mehr lässt.

Wer keinen funktionierenden Prozess hat, hat kein Update-Problem. Er sitzt auf einem Compliance-Problem, das gerade noch keiner ausgelöst hat.

Welche Themen würden euch in dieser Serie konkret weiterhelfen? Lifecycle, Debugging, Architektur, Multi-Tenancy – schreibt es in die Kommentare, dann fließt das in die nächsten Wochen ein.