Kubernetes 1.36 - Haru

• User Namespaces. Root im Container, niemand auf dem Host

• Fine-Grained Kubelet API Authorization ist stable. Nodes dürfen keine Secrets anderer Nodes lesen

• Mutating Admission Policies sind GA. Mutations per Common Expression Language (CEL)

• SELinux Volume Labels sind GA und deutlich schneller

• ImageVolume ist GA. OCI-Artifacts direkt als Container-Volumes mounten

• Dynamic Resource Allocation (DRA) setzt seine Reise fort: AdminAccess, Prioritized Alternatives und PodResources sind stable

• HPA-Skalierung auf Null für benutzerdefinierte Metriken ist im Alpha-Status

• gitRepo-Volumes sind deaktiviert, waren bereits seit v1.11 veraltet

• ExternalIPs bei Services ist veraltet. CVE-2020–8554 wird damit endgültig entschärft.

User-Namespaces erhöhen die Isolierung von Pods, indem sie die User Prozesse im Container von den Usern auf dem Host trennen.

Dies ist besonders nützlich für Pods, die als Root laufen müssen. Man kann User-Namespaces nutzen, um Prozesse als Root innerhalb des Pods laufen zu lassen, während sie tatsächlich auf dem Host unprivilegiert (Nicht als Root) ausgeführt werden.

Falls ein solcher Pod kompromittiert wird und der Angreifer es schafft, aus dem Container auszubrechen, ist der Angreifer trotzdem ein unprivilegierter Benutzer auf der Node.

Diese Funktion wird aktiviert, indem hostUsers: false in der Pod-Spec gesetzt wird:

apiVersion: v1
kind: Pod
metadata:
  name: user-namespace
spec:
  hostUsers: false
  containers:
    - name: test
      image: busybox
      command: ["sleep", "3600"]

$ kubectl exec user-namespace -- id
uid=0(root) gid=0(root) groups=0(root),10(wheel)

$ kubectl get pod user-namespace -o jsonpath='{.spec.hostUsers}'
false

In Kubernetes hängt Sicherheit maßgeblich davon ab, wie fein granular Zugriffe über RBAC gesteuert werden. Bisher musste für eine Node immer die gesamte Berechtigung Freigegeben werden (nodes/proxy). Dies widerspricht klar dem "Least Privileges" Ansatz.

Mit der Fine-Grained-Authorization für die Kubelet API ist es nun möglich, gezielt Zugriff auf einzelne Ressourcen zu gewähren, zum Beispiel:

• nodes/configz

• nodes/healthz

• nodes/pods

Die meisten Anpassungen, die ein Admission Controller vornimmt, sind einfache Änderungen an den Manifesten. Zum Beispiel das Setzen von Labels oder das Hinzufügen von Sidecars. Mit dieser Erweiterung gibt es jetzt die Möglichkeit, solche Änderungen direkt in YAML über die Common Expression Language (CEL) zu definieren. In vielen Fällen wird dadurch ein zusätzlicher Webhook überflüssig.

Möchtest du jedem Pod automatisch ein managed-by Label geben? Dann geht das ab sofort so:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: label-injector
spec:
  reinvocationPolicy: Never
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["pods"]
  mutations:
  - patchType: "ApplyConfiguration"
    applyConfiguration:
      expression: >
        Object{
          metadata: Object.metadata{
            labels: {"managed-by": "cel-policy"}
          }
        }

SELinux-Labels auf Volumes sorgen dafür, dass Container nur auf die vorgesehenen Dateien zugreifen können.

Diese Funktion beschleunigt das Einbinden von PersistentVolumes bei Verwendung von SELinux. Durch die Nutzung der Option context zum Zeitpunkt des Mountens wird der Security Context direkt auf das gesamte Volume angewendet, anstatt die Dateien einzeln und rekursiv anzupassen.

Im Bereich Storage und Volumes gibt es einige Änderungen, die wir hier einmal als Übersicht dargestellt haben.

Portworx CSI Migration (KEP #2589) abgeschlossen – in-tree Volumes werden transparent zum CSI-Treiber umgestellt.

VolumeGroupSnapshot (KEP #3476) stabil – Snapshot einer Gruppe von Volumes als atomare Einheit (z. B. Datenvolumes + WAL).

Mutable CSINode Allocatable (KEP #4876) stabil – CSI-Treiber können künftig die Größe eines Volumes zur Laufzeit aktualisieren, ohne das ein Pod Neustart erforderlich wird.

CSI ServiceAccount Token Secrets (KEP #5538) GA – CSI-Treiber können Tokens von Service Accounts direkt für die Authentifizierung mit externen Storage Providern nutzen.

OCI-Images können direkt als Read Only Volume Mount genutzt werden.

Ein einfaches Anwendungsbeispiel sind Webserver wie nginx: Alle Website-Pods können nun dasselbe Basis-Image nutzen und die Konfiguration sowie Web-Inhalte in einem separaten, schlanken OCI-Image bereitstellen.

apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: app
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: oci-content
      mountPath: /oci
  volumes:
  - name: oci-content
    image:
      reference: busybox:latest
      pullPolicy: IfNotPresent

Test: OCI-Dateisystem mountet Read Only unter /oci:

$ kubectl exec image-volume -- ls /oci
bin  dev  etc  home  lib  lib64  root  tmp  usr  var

$ kubectl exec image-volume -- touch /oci/test
touch: /oci/test: Read-only file system

DRA ist ein Kubernetes-Feature, mit dem Ressourcen zwischen Pods angefordert und geteilt werden können. Dabei handelt es sich häufig um angeschlossene Hardware an den Nodes.

Mit DRA definieren Gerätetreiber und Cluster-Admins sogenannte Device Classes, die in Workloads geclaimt werden können. Kubernetes weist passende Devices den jeweiligen Claims zu und platziert die entsprechenden Pods auf Nodes, die Zugriff auf die zugewiesenen Devices haben.

Die Ressourcenzuweisung mit DRA ähnelt der dynamischen Volumenbereitstellung über PersistentVolumes und PersistenVolumeClaims.

Mit Kubernetes 1.36 ergeben sich folgende Änderungen:

• DRA AdminAccess (KEP #5018) – Admins können privilegierten Zugriff auf spezifische Geräte gewähren

• DRA Prioritized Alternatives (KEP #4816) – Workloads können eine priorisierte Liste bevorzugter Ressourcen angeben; Kubernetes wählt die beste verfügbare Option

• DRA PodResources Extension (KEP #3695) – Erweiterung der PodResources-API, um DRA-verwaltete Ressourcen innerhalb des Pod Status sichtbar zu machen

Das Feld externalIPs im Service-Spec ist ab sofort deprecated. Damit entfällt die bisherige Möglichkeit, beliebige externe IPs direkt auf eure Services zu routen.

Das Thema Security war hier schon länger ein Problem – u.a. ermöglichte dieses Feld Man-in-the-Middle-Angriffe auf Service-Traffic im Cluster (CVE-2020-8554).

Ab Kubernetes v1.36 erscheinen bei der Nutzung entsprechende Warnungen, die vollständige Entfernung dieser Funktion ist für Kubernetes v1.43 geplant.

Wenn eure Services aktuell noch auf externalIPs setzen, solltet ihr frühzeitig Alternativen prüfen: Empfohlen werden z. B. LoadBalancer-Services, NodePorts für die einfache Port-Freigabe oder die Gateway API als moderne, flexible und sichere Lösung für externen Traffic.

Um die Sicherheit des Kubernetes-Ökosystems zu gewährleisten, haben das SIG Network und das Security Response Committee das Ingress NGINX-Projekt zum 24. März 2026 eingestellt.

Seit diesem Datum gibt es keine neuen Releases, Bugfixes oder Sicherheitsupdates mehr. Bestehende Deployments von Ingress NGINX funktionieren weiterhin und Helm-Charts sowie Container-Images bleiben verfügbar, erhalten jedoch keine Aktualisierungen mehr.

Alle Details dazu im offiziellen Kubernetes Blog