Kubernetes-Security-Features, die für Anwendungsteams wirklich zählen

Kubernetes-Release-Notes sind lang. Die meisten Anwendungsteams müssen nicht jede API-Änderung, jedes Feature Gate und jede Graduation lesen. Sie müssen aber wissen, wann ein Release Sicherheits- und Betriebsannahmen verändert, von denen ihre Workloads abhängen.

Kubernetes 1.33 und 1.34 sind gute Beispiele. Interessant sind nicht nur neue Commands oder Nischen-APIs. Mehrere Änderungen zeigen in Richtung eines praktischeren Plattform-Security-Modells: bessere Isolation von Container-Identitäten, expliziteres Linux-Gruppenverhalten, kurzlebigere Image-Pull-Credentials und sicherere Betriebsdefaults.

Für Anwendungsteams ist die Frage nicht: "Was ist neu in Kubernetes?" Die Frage ist: "Welche dieser Änderungen sollte beeinflussen, wie wir Produktions-Workloads betreiben?"

User Namespaces: Root im Container sollte nicht Root auf dem Host bedeuten

Container Security hatte immer eine unbequeme Wahrheit: Ein Prozess kann im Container als root laufen. Container-Isolation reduziert Risiko, aber root bleibt eine sensible Identität. Wenn ein Container Escape oder eine Kernel-Schwachstelle auftaucht, ist relevant, wie Container-root auf Host-root gemappt wird.

User Namespaces helfen, indem User IDs im Container auf andere User IDs auf dem Host abgebildet werden. Vereinfacht: Der Prozess kann glauben, im Container root zu sein, ohne root-äquivalent auf dem Host zu sein.

Das ist kein magischer Schutz. Es ersetzt nicht Least Privilege, seccomp, AppArmor, SELinux, Admission Policy oder Runtime Hardening. Aber es reduziert Blast Radius sinnvoll, wenn es korrekt eingesetzt wird.

Die CNCF hat den Kubernetes-1.33-Impact von User Namespace Isolation detailliert beschrieben, inklusive warum das für Pod Security relevant ist und was Plattformteams vor dem Rollout validieren müssen. Der Artikel ist ein guter praktischer Einstieg.

Der operative Haken ist Kompatibilität. User Namespaces berühren Runtime-Verhalten, Storage, File Ownership und manchmal Annahmen in Container Images. Adoption sollte geplant sein: mit risikoarmen Namespaces starten, Runtime und Storage Driver validieren, Dateiberechtigungen prüfen und echte Workloads beobachten.

Für Anwendungsteams ist die nützliche Erkenntnis:

Wenn die Plattform Workloads mit User Namespace Isolation ausführen kann, wird root im Container weniger gefährlich. Das lohnt sich besonders für Multi-Tenant-Cluster, Build-Workloads, Preview-Umgebungen und Third-Party-Images.

Supplemental Groups: Versteckter Dateizugriff bleibt Zugriff

Kubernetes Security Contexts erlauben Linux-Identitätseinstellungen wie runAsUser, runAsGroup, fsGroup und supplementalGroups. Viele Teams nehmen an, dass sie damit die Prozessidentität im Container vollständig verstehen.

Historisch war diese Annahme unvollständig.

Standardmäßig kann Kubernetes Gruppen aus dem Pod Security Context mit Gruppenzugehörigkeiten aus der /etc/group des Container Images zusammenführen. Dadurch kann ein Containerprozess zusätzliche Gruppen bekommen, die im Pod Spec nicht offensichtlich sind. In vielen Fällen ist das harmlos. Bei sicherheitssensiblen Volume-Zugriffen kann es überraschend sein.

Kubernetes 1.33 hat supplementalGroupsPolicy nach Beta bewegt und das Feature Gate standardmäßig aktiviert. Der offizielle Kubernetes-Blog erklärt die Motivation klar: Implizite Gruppenzugehörigkeiten aus dem Image können Volume-Zugriff beeinflussen, und die neue Policy gibt Plattformteams präzisere Kontrolle. Der Kubernetes-1.33-Artikel ist die Quelle für das genaue Verhalten und Upgrade-Hinweise.

Praktisch geht es um den Unterschied zwischen gemergten Gruppen und strikt explizit definierten Gruppen. Für regulierte Umgebungen, Shared Storage, Multi-Tenant-Plattformen oder Workloads mit sensiblen Daten ist explizite Identität meist besser als überraschende Identität.

Adoption:

• Workloads mit Shared Volumes auditieren.
• Prüfen, ob Images zusätzliche Gruppen in /etc/group definieren.
• Striktes Gruppenverhalten testen, bevor es erzwungen wird.
• Gewünschte runAsUser, runAsGroup, fsGroup und supplementalGroups dokumentieren.
• Policy zu Namespace- oder Workload-Standards machen, nicht zu Tribal Knowledge.

Das ist kein Feature, das Entwickler begeistert. Es ist trotzdem wichtig, weil Dateizugriffsfehler langweilig wirken, bis sie zu Datenexposure werden.

Image-Pull-Credentials: Weg von langlaufenden Secrets

Container-Registry-Credentials sind ein weiteres Feld, in dem viele Cluster altes Risiko mittragen. Ein Namespace hat ein Image-Pull-Secret. Ein Service Account referenziert es. Das Secret ist langlaufend. Dieselben Credentials werden vielleicht über viele Workloads wiederverwendet. Rotation ist nervig und passiert selten.

Kubernetes 1.34 bewegt sich weiter in Richtung eines besseren Modells: Service-Account-Token-Integration für kubelet Image Credential Providers ist nach Beta graduiert. Der Release-Blog beschreibt das Ziel: kubelet kann kurzlebige, audience-bound Service-Account-Tokens für Image-Pull-Authentifizierung anfordern, sodass Registry-Autorisierung stärker an die Identität des Pods gebunden wird. Die Kubernetes-1.34-Ankündigung hebt diese Richtung hervor.

Es gibt auch einen dedizierten Blogpost zur Beta-Graduation. Er beschreibt das Feature als Schritt weg von langlaufenden Image-Pull-Secrets.

Für Anwendungsteams ist das relevant, weil Image Pulls Teil des Deployment-Pfads sind. Wenn Pull Credentials breit geteilt, langlaufend und schwer rotierbar sind, wird ein Anwendungsdeployment zum Plattform-Security-Thema.

Kurzlebige, audience-bound Credentials sind der bessere Default. Sie machen Kompromittierung weniger dauerhaft und binden Zugriff enger an Workload Identity. Die Details hängen von Registry-Support, kubelet Credential Provider Configuration, Cloud-Provider-Integration und Plattformreife ab.

Die richtige Frage ist nicht: "Können wir das morgen nutzen?" Sondern: "Was ist unser Weg weg von statischen Image-Pull-Credentials?"

Sichere Defaults brauchen Rollout-Disziplin

Security-Features scheitern, wenn sie als Checkbox behandelt werden. Kubernetes gibt Plattformteams Knöpfe. Produktionsplattformen brauchen Rollout-Pläne.

Für Features wie User Namespaces, strikte Supplemental Groups und service-account-basierte Image-Pull-Credentials würde ich nicht mit einem Cluster-weiten Mandat starten. Ich würde mit einer Kompatibilitätskarte beginnen:

• Welche Runtime- und Kubernetes-Versionen unterstützen das Feature?
• Welche Storage Driver sind betroffen?
• Welche Workloads laufen heute als root?
• Welche Images verlassen sich auf implizite File Ownership oder Gruppen?
• Welche Namespaces eignen sich risikoarm für frühe Rollouts?
• Welche Admission Policies müssen sich ändern?
• Welche Teams brauchen Dokumentation vor Enforcement?
• Welche Metriken oder Alerts bestätigen einen gesunden Rollout?

Danach progressiv:

1. Gewünschte Workload-Security-Baseline dokumentieren.
2. In nicht-kritischem Namespace testen.
3. Observability für Permission Errors und Rollout-Probleme ergänzen.
4. Templates, Helm Charts und Plattformbeispiele aktualisieren.
5. Neue Workloads zuerst erzwingen.
6. Bestehende Workloads nach Risiko migrieren.
7. Ausnahmen mit Owner und Ablaufdatum erfassen.

Das klingt langsamer als "Feature einschalten". Es ist auch der Weg, Produktion nicht unter dem Banner von Hardening zu brechen.

Was Anwendungsteams ihre Plattform fragen sollten

Anwendungsteams müssen nicht jedes Kubernetes-Feature besitzen. Sie sollten trotzdem wissen, welche Fragen sie stellen.

Für Kubernetes 1.33 und 1.34:

• Kann unser Cluster Pods mit User Namespace Isolation ausführen?
• Welche Workloads müssen noch als root laufen, und warum?
• Sind Supplemental Groups explizit, oder können Image-Gruppen Runtime-Zugriff beeinflussen?
• Laufen unsere Image-Pull-Credentials ab, oder sind es langlaufende Secrets?
• Sind Registry-Rechte an Workload Identity, Namespace oder breite Shared Credentials gebunden?
• Definieren unsere Helm Charts und Templates konsistente securityContext-Defaults?
• Sind Ausnahmen sichtbar, reviewed und zeitlich begrenzt?
• Testet unsere CI/CD-Pipeline Workload-Security-Settings vor dem Deployment?

Diese Fragen erzeugen nützlichen Druck. Sie bewegen Security aus der Theorie in den Application-Delivery-Pfad.

Release Notes sind keine Plattformstrategie

Kubernetes bewegt sich schnell. Release Notes zu lesen ist notwendig. Es reicht nicht.

Der Wert entsteht, wenn Release Notes in Plattformentscheidungen übersetzt werden:

• Welche Features werden Defaults?
• Welche bleiben Opt-in?
• Welche sind durch Runtime, Storage oder Cloud-Provider blockiert?
• Welche brauchen Developer Education?
• Welche reduzieren Risiko genug, um Migrationsarbeit zu rechtfertigen?

Diese Übersetzung ist Platform Engineering. Genau dort kämpfen viele Organisationen. Sie upgraden Cluster, behalten aber jahrelang dieselben Workload-Defaults. Sie ergänzen Policy Engines, definieren aber keine praktische Security-Baseline.

Kubernetes 1.33 und 1.34 geben Teams nützliche Bausteine. User Namespaces reduzieren Risiko von Container-root-Workloads. Supplemental Group Policy macht Dateizugriff expliziter. Service-account-basierte Image-Pull-Credentials reduzieren statische Secrets. Keines dieser Features hilft viel, wenn es nicht in Build, Deployment und Betrieb integriert wird.

Das Ziel sind langweilige, sichere Defaults: Entwickler bekommen sichere Beispiele. CI erkennt offensichtliche Fehler. Admission Policies erzwingen wichtige Grenzen. Ausnahmen sind sichtbar. Operations kann erklären, warum ein Workload so konfiguriert ist.

Wenn Ihr Team Kubernetes oder OpenShift, EKS, GKE, AKS oder private Cluster mit älteren Workload-Defaults betreibt, ist jetzt ein guter Moment für ein Platform-Hardening-Review.