Kubernetes Kubernetes 1.25 "Combiner" - Ein Überblick

Kubernetes 1.25 wurde am 23. August veröffentlicht und hört auf den Namen Combiner. Der Release umfasst rund 40 Erweiterungen in unterschiedlichsten Bereichen, darunter viele Neuerungen, die nun den Status "stable" erhalten und von der Community bereits mit Spannung erwartet wurden. Einige interessante Punkte haben wir im Folgenden kurz zusammengefasst.

PodSecurityPolicy entfernt

PodSecurityPolicy arbeitet auf Cluster-Ebene und definiert eine Reihe von Bedingungen, die Pods erfüllen müssen, um im System akzeptiert zu werden. Auf diesem Weg ließen sich in der Vergangenheit die Zugriffsberechtigungen und damit der Handlungsspielraum von Pods verwalten und einschränken. PodSecurityPolicy ist seit Version 1.21 als veraltet markiert und wird mit dem Release von Kubernetes 1.25 endgültig entfernt.

Die Aufgaben von PodSecurityPolicy übernimmt in Zukunft PodSecurityAdmission. PodSecurityAdmission ist eine Zulassungssteuerung auf Namespace-Level, die Pods anhand von Sicherheitskontrollen bewertet, um Funktionen im Pod zuzulassen oder zu verweigern. Sicherheitsstandards werden auf drei Ebenen umgesetzt.

• warn: Verstöße gegen die Richtlinie führen zu einer Warnung für den Benutzer, sind aber ansonsten zulässig.
• audit: Verstöße gegen die Richtlinie führen dazu, dass dem im Audit-Protokoll aufgezeichneten Ereignis ein Audit-Vermerk hinzugefügt wird, sind aber ansonsten zulässig.
• enforce: Verstöße gegen die Richtlinien führen zur Ablehnung des Pods

Wenn ihr PodSecurityPolicy nutzt, solltet ihr euch vor einem zukünftigen Update auf 1.25 also noch einmal genau mit der Thematik auseinandersetzen. Auf kubernetes.io wird Migrations-Prozess ausführlich erklärt.

CSI Migration

CSI (Container Storage Interfaces) vereinfacht es Drittanbietern, Storage-Lösungen zu entwickeln, ohne dabei vom Kubernetes Release-Zyklus abhängig zu sein. CSI-Migrations ist eines von 14 Features, dass in der aktuellen Version 1.25 in den Status "stable" überführt wird und damit ein wichtiger Meilenstein bei der Entwicklung, weg von In-Tree-Volume-Plugins hin zu Out-of-Tree-CSI-Treibern.

• entfernt: scaleio, flocker, quobyte, storageos
• GA: glusterFS, Portworkx

cgroups v2 graduating to stable

cgroups ist eine der grundlegenden Linux-Kernel-Funktionen zur Organisation und Verwaltung von Container-Ressourcen auf Nodes und der Nachfolger, die cgroups api-v2 ist nun seit etwa zwei Jahren im Stable-Betrieb. Mit Combiner zieht Kubernetes nach und sichert die Kompatibilität mit der wachsenden Zahl von Distribution, die cgroups api-v2 nutzen. Möglich ist von jetzt an der Betrieb von non-root-kubernetes-Komponeneten, besonders wichtig rootless Containers. So eröffnen sich viele neue Fähigkeiten für Sicherheitszwecke und es ist großartig, dass diese in der Produktion eingesetzt werden können.

Ephemeral Containers ab jetzt GA

Grundsätzlich gilt – in einem laufenden Pod können keine weiteren Container mehr gestartet werden. Anders verhält sich das mit „vergänglichen Containern“ (Ephemeral Containers), die ab Version 1.25 voll verfügbar sind. Ephemeral Containers können in bestehenden Pods gestartet werden und beliebige Befehle ausführen. Das macht interaktives Troubleshooting und Debugging in Produktionsumgebungen deutlich praktikabler. Ein typischer Anwendungsfall könnte also sein: kubectl exec ist nicht anwendbar, weil der Container abgestürzt und das Container-Image keine Debugging-Tools umfasst. Ein Ephemeral Container lässt sich dann im laufenden Pod starten. Das kann besonders hilfreich beim Troubleshooting wiederkehrender Bugs im laufenden Betrieb sein.

• Ephemeral Container dürfen keine Ports haben
• die Ressourcen-Zuweisungen sind unveränderlich
• eine Übersicht der verfügbaren Einstellungsmöglichkeiten findet ihr hier

User Namespaces jetzt alpha

Ein lang erwartetes Feature zur Verringerung der Angriffsfläche von Container-Images, da es aufgrund von zu weit reichenden Privilegien von z.B. Pods in der Vergangenheit immer wieder zu Problemen kommen konnte. User Namespaces werden vom Linux-Kernel schon seit einiger Zeit unterstützt und sind ab Version 1.25 Teil von Kubernetes.

Sie stellen eine zusätzliche Isolationsebene zwischen Pod und Host dar und unterscheiden sich in vielen Bereichen von den bekannten Cluster Namespaces. Das Augenmerk liegt auf der Beseitigung von Schwachstellen im Zusammenhang mit Pod-/Container-Flucht. Vereinfacht gesagt erhalten Prozesse auf Container-Ebene zwei verschiedene Identitäten. Eine UID auf Pod-Ebene und eine GIP außerhalb, deren Berechtigungen eingeschränkt sind. So lassen sich bekannte und problematische Schwachstellen entschärfen.