Warum sich Kubernetes 1.35 wie ein Security-First-Release anfühlt

Kubernetes-Updates kommen normalerweise in einem vertrauten Rhythmus daher: eine Handvoll Komfort-Verbesserungen, ein paar Aufräumarbeiten hinter den Kulissen, und wenn die Sterne günstig stehen, vielleicht ein oder zwei auffällige neue Features. Version 1.35 bricht mit diesem Muster. Dieses Release fühlt sich anders an. Es fühlt sich an, als hätten die Kubernetes-Maintainer endlich die Sicherheits-Checkliste zur Hand genommen, die seit Jahren in der Ecke vor sich hin wuchs, und gesagt: Okay, das arbeiten wir jetzt alles auf einmal ab.

Und das haben die Leute definitiv bemerkt. Engineers, die sich durch den Changelog wühlen, kommen immer wieder auf denselben Punkt zurück: Dieses Release ist auf subtile Weise gewaltig für alle, denen das Härten ihrer Cluster wichtig ist … und ein bisschen nervenaufreibend für alle, die sich auf älteres Verhalten verlassen haben.

Eine Aufschlüsselung der Änderungen, die in Community-Diskussionen kursiert, deutet auf etwas Größeres hin als ein typisches inkrementelles Update. Es ist ein Release, bei dem die Messlatte höher gelegt wird. Bei dem Altlasten aufgeräumt werden. Bei dem Türen geschlossen werden, die länger offen standen, als sie sollten. Bei dem Kubernetes sicherer gemacht wird, selbst wenn das manche Setups aufstöhnen lässt.

Schauen wir uns an, was sich tatsächlich ändert – und warum sich dieses Release wie das sicherheitsgetriebenste anfühlt, das Kubernetes seit Langem geliefert hat.

Sicherheitsänderungen, die Ihnen den Tag verderben könnten

Ein Cluster-Upgrade ist nichts Beängstigendes – bis der Satz „das könnte etwas kaputt machen" auftaucht. Und 1.35 hat davon ein paar.

1. Auf Wiedersehen, cgroup v1 (#5573)

Keine Überraschung – das bahnt sich schon eine Weile an –, aber dass Kubernetes cgroup v1 offiziell fallen lässt, ist einer dieser Momente, die in der Produktion härter treffen, als man erwartet.

Manche Workloads haben sich jahrelang still und leise auf Eigenheiten von v1 verlassen. Das Community-Echo dazu ist im Grunde eine Mischung aus „Gott sei Dank, wurde auch Zeit" und „wenn das mein Setup kaputt macht, wechsle ich die Plattform".

Das ist eine große Kompatibilitätsklippe, und das wissen die Leute auch.

2. Erzwungene Validierung bei Secret-basiertem Image-Pull (#2535)

Diese Änderung verschärft, wie Kubernetes mit Images umgeht, die für den Pull auf Secrets angewiesen sind. Wenn Ihr Cluster hier irgendwelche unscharfen oder inkonsistenten Konfigurationen hatte, wird die neue Durchsetzung das schnell aufdecken.

Das ist die Art von Fix, die aus Sicherheitssicht absolut Sinn ergibt – Images ohne die richtigen Secret-Prüfungen pullen zu lassen, war schon immer ein riskanter blinder Fleck –, aber es ist auch die Art von Sache, die verstaubte Ecken in CI/CD-Pipelines freilegt.

3. Umstieg von SPDY auf WebSockets (#4006)

SPDY hält sich schon länger, als irgendjemand erwartet hätte. Kubernetes verschiebt nun endlich seine verbliebenen Abhängigkeiten in Richtung WebSockets.

Das sollte keine Cluster zum Explodieren bringen, zwingt aber einige Operatoren definitiv dazu, über Tooling, Proxys und ältere Sidecars nachzudenken, die noch SPDY erwartet haben. WebSockets bringen einen moderneren, sichereren Ansatz mit sich, aber wie bei den meisten Protokollwechseln trifft das an ungünstigen Stellen, bis alles nachgezogen hat.

4. Gehärtete Kubelet-Zertifikatsvalidierung (#4872)

Diese Änderung ist weniger auffällig, aber vermutlich eine der wichtigsten. Der Kubernetes-API-Server verschärft nun die Validierung von Kubelet-Serving-Zertifikaten.

Übersetzt heißt das: weniger Gelegenheiten für falsche Identitätsannahmen, weniger Schlupflöcher für falsch konfigurierte Nodes und weniger Angriffspfade für Impersonation.

Das ist die Art von Sicherheitshärtung, die sich mit der Zeit auszahlt – besonders in großen Clustern, in denen die Zertifikatsverwaltung gelegentlich aus dem Ruder läuft.

Die neuen Sicherheitsfeatures, die tatsächlich alles verändern

Über die Breaking Changes hinaus bringt Kubernetes 1.35 mehrere neue Erweiterungen mit, die die Plattform in eine modernere, stärker abgeriegelte Zukunft treiben.

1. Eingeschränkte Impersonation (#5284)

Impersonation war schon immer ein zweischneidiges Schwert. Sie ist ein notwendiges Feature für Tools, Operatoren und Automatisierung … aber auch eine der beängstigendsten Berechtigungen, die man irgendetwas in seinem Cluster geben kann.

Die neue Erweiterung für eingeschränkte Impersonation erlaubt es Ihnen, zu begrenzen, wer – oder was – welche Service Accounts oder Benutzergruppen imitieren darf.

Betrachten Sie es so, als würde man einem Feature endlich Sicherheitsgurte verpassen, die es eigentlich von Anfang an hätte haben sollen.

2. Flagz für Kubernetes-Komponenten (#4828)

Kurz gesagt: Kubernetes-Komponenten können jetzt ihre Runtime-Flags auf strukturierte, transparente Weise offenlegen.

Warum ist das für die Sicherheit wichtig?

Weil sich Fehlkonfigurationen in Flags verstecken, und die Möglichkeit, sie sauber zu introspizieren, einer der schnellsten Wege ist, um Drift zu erkennen, seltsames Verhalten zu diagnostizieren oder etwas zu erwischen, das eigentlich nicht aktiviert sein sollte.

In komplexen Clustern ist Sichtbarkeit die halbe Miete.

3. HostNetwork-Pods dürfen User Namespaces nutzen (#5607)

Das ist ein großer Schritt für Umgebungen, die Workloads aggressiver isolieren wollen. User Namespaces sind ein seit Langem gewünschtes Feature zur Verbesserung der Multi-Tenant-Sicherheit.

Wenn HostNetwork-Pods auf diese Isolation zugreifen können, verkleinert das den Explosionsradius privilegierter Workloads.

Es ist kein magischer Schutzschild, aber es ist Fortschritt – und Fortschritt ist selten, wenn es um Berechtigungen auf Netzwerkebene geht.

4. CSI-Treiber-Opt-in für SA-Tokens über Secrets (#5538)

CSI-Treiber erhielten historisch gesehen Service-Account-Tokens, egal ob sie sie brauchten oder nicht. Sie können sich denken, warum das ein Problem war. Version 1.35 dreht das um: Treiber müssen jetzt aktiv zustimmen.

Least Privilege als Standard – endlich.

Features, die jetzt standardmäßig aktiviert sind – und was sie für die Sicherheit bedeuten

Manche Erweiterungen saßen ewig hinter Feature Gates und warteten auf den Moment, in dem Kubernetes sagen würde: „Okay, alle sind bereit." Version 1.35 legt bei einigen davon den Schalter um.

1. Pod-Zertifikate (#4317)

Zertifikatsautomatisierung innerhalb von Kubernetes fühlte sich schon immer ein bisschen an wie das Spielen mit Kabeln, die Funken schlagen, wenn man sie falsch berührt. Pod-Zertifikate machen Identität zu einem echten First-Class-Konzept, einfacher zu automatisieren und schwerer zu missbrauchen.

Viele haben darauf gewartet, dass dieses Feature die experimentelle Phase verlässt, und seine Beförderung in 1.35 signalisiert echte Reife bei der Workload-Identität.

2. User Namespaces für Pods (#127)

Das ist Teil eines größeren Bogens: die Lücke zwischen Root innerhalb eines Containers und Root auf dem Host zu verkleinern. User Namespaces waren jahrelang das fehlende Puzzleteil, und sie standardmäßig zu aktivieren, bewegt Kubernetes hin zu einer sichereren Basis für alle Workloads – selbst solche, die nicht mit strikter Isolation im Hinterkopf entworfen wurden.

3. OCI-Artefakte / Images als VolumeSource (#4639)

Das ist nicht streng genommen ein Sicherheitsfeature, hat aber echte Auswirkungen. Volumes aus OCI-Artefakten beziehen zu können, eröffnet sauberere, konsistentere Wege, um Read-only-Inhalte zu verteilen.

Weniger maßgeschneiderte Systeme, weniger seltsame Randfälle und weniger Gelegenheiten für irgendjemanden, etwas in Ihre Volume-Mounts einzuschmuggeln.

4. Trennung von kubectl-Benutzereinstellungen und Cluster-Configs (#3104)

Das ist eine stille, aber wichtige Verschiebung. Benutzereinstellungen mit Cluster-Configs zu vermengen, machte es leichter für Fehler oder schlechte Defaults, in die Produktion durchzusickern.

Durch die Trennung reduziert Kubernetes das Risiko von „Ups, das sollte nicht passieren"-Momenten während Deployments.

5. Entfernung der Gogo-Protobuf-Abhängigkeit (#5589)

Sicherheit und Serialisierungsbibliotheken haben eine interessante Beziehung zueinander. Ältere Abhängigkeiten zu entfernen – besonders solche mit langer Geschichte und durchwachsener Sicherheitsbilanz – ist immer ein Gewinn.

6. Strukturierte Authentifizierungskonfiguration (#3331)

Diese Erweiterung räumt auf, wie Authentifizierungseinstellungen ausgedrückt werden, wodurch Fehler schwerer zu machen und leichter zu erkennen sind. Sauberere Config = weniger Überraschungen.

7. Feingranulare Kontrolle über SupplementalGroups (#3619)

RBAC ist nicht der einzige Ort, an dem Zugriffskontrolle wichtig ist. SupplementalGroups beeinflussen Dateiberechtigungen innerhalb von Pods, und feingranularere Kontrolle erlaubt es Operatoren, die Workload-Isolation präziser an ihre Sicherheitsmodelle anzupassen.

8. Drop-in-Konfigurationsverzeichnis für Kubelet (#3983)

Das klingt langweilig, bis man ein ganzes Wochenende damit verbracht hat, ein falsch konfiguriertes Flag aufzuspüren. Ein richtiges Drop-in-Konfigurationsverzeichnis bedeutet vorhersehbare Overrides, konsistente Updates und weniger versehentliche Änderungen. Sicherheit liebt Vorhersehbarkeit, und das gibt Ihnen mehr davon.

Warum sich 1.35 wie ein Wendepunkt anfühlt

Um dieses Release liegt eine gewisse Stimmung – dass Kubernetes in eine neue Ära eintritt, in der Sicherheit kein Nebenschauplatz mehr ist, sondern die Hauptgeschichte.

Viele Operatoren haben sich diesen Wandel gewünscht. Kubernetes ist erwachsen geworden. Die leichten Erfolge sind aufgebraucht. Die Plattform ist kampferprobt, weit verbreitet im Einsatz und sieht sich nun modernen Bedrohungen gegenüber, die nicht einmal auf dem Radar waren, als das Projekt begann.

Version 1.35 liest sich wie eine Antwort auf diese Realität.

Es schließt alte Türen, ersetzt in die Jahre gekommene Annahmen und legt mehr Macht in die Hände von Administratoren, die engere Kontrolle wollen. Selbst die Änderungen, die riskieren, die Produktion zu brechen, tun das mit einem klaren Ziel: sicherere Defaults, bessere Isolation, weniger Wege, auf denen still und heimlich etwas schiefgehen kann.

Ist es perfekt? Natürlich nicht. Jedes Release, das so viele sensible Bereiche berührt, wird für Kopfschmerzen sorgen. Irgendjemand da draußen wird garantiert upgraden und dann ins Leere schreien, wenn etwas Unerwartetes kaputtgeht. Das gehört dazu, wenn man Kubernetes im großen Maßstab betreibt – die Kompromisse hören nie auf.

Aber insgesamt betrachtet wirkt Kubernetes 1.35 ehrlich in Bezug auf die Zukunft der Plattform. Wir bewegen uns in eine Welt, in der Workloads eine starke Identität brauchen, Container eine Isolation brauchen, die tatsächlich etwas bedeutet, und Infrastruktur-Teams sich Legacy-Verhalten mit unsichtbaren Risiken nicht mehr leisten können.

Dieses Release erkennt diesen Wandel nicht nur an. Es stellt sich ihm mit voller Kraft.