0800 71 20000
Kontakt
...
Kubernetes 1.36 Security: Upgrade-Checkliste für Teams

Kubernetes 1.36 Security: Upgrade-Checkliste für Teams

So prüfst Du Kubelet-RBAC, User-Namespaces, CEL-Policies und EKS Pod Identity vor dem Upgrade.

Ein Upgrade auf Kubernetes 1.36 betrifft nicht nur API-Kompatibilität, Control-Plane-Komponenten und Node-Images. Vor dem Rollout solltest Du RBAC, Pod-Isolation, Admission-Regeln und Cloud-Identity gezielt prüfen. Besonders relevant ist das, wenn Dein Cluster Prometheus, Fluent Bit, OpenTelemetry Collector, AWS-Controller oder eigene Plattform-Operatoren nutzt: Diese Komponenten arbeiten häufig mit weitreichenden Service-Account-Rechten.

Warum Kubernetes 1.36 Security auf Deine Roadmap gehört

Behandle Kubernetes 1.36 Security als eigenes Arbeitspaket im Upgrade-Plan. Die wichtigsten Kontrollfragen sind konkret: Welche Service-Accounts dürfen Kubelet-Endpunkte lesen? Welche Pods laufen weiterhin mit Host-UIDs? Welche Defaults ergänzt Admission-Control? Welche AWS-Rechte hängen an Kubernetes-Service-Accounts?

Prüfe vor dem Upgrade die Release Notes Deiner Kubernetes-Distribution und Deiner Managed-Kubernetes-Plattform. Nicht jedes Feature ist in jedem Cluster automatisch aktiv; Feature-Gates, API-Versionen und Default-Werte können sich zwischen Upstream-Kubernetes, EKS, AKS, GKE und selbst betriebenen Clustern unterscheiden.

Wenn Dein Team Runbooks, Pod Security Admission und API-Server-Mechanismen gemeinsam nachvollziehen soll, passen Grundlagen aus Cloud-Native-Schulungen und IT-Security-Schulungen als Ergänzung zur praktischen Upgrade-Vorbereitung.

Kubelet RBAC nodes/proxy prüfen und breite Rechte ersetzen

Die Kubelet-API ist sicherheitskritisch, weil sie je nach Endpunkt Pod-Informationen, Node-Metriken, Container-Logs und Zugriffspfade im Umfeld laufender Container bereitstellt. Ein pauschales nodes/proxy in ClusterRoles gibt Monitoring- und Observability-Komponenten oft mehr Zugriff, als sie für Scraping, Health Checks oder Log-Abfragen benötigen.

Prüfe, ob Dein Kubernetes-1.36-Cluster feinere Kubelet-Subresources unterstützt und welche Defaults Deine Distribution setzt. Ersetze nodes/proxy dort durch gezieltere Rechte wie nodes/metrics, nodes/stats oder nodes/log, wo die jeweilige Komponente nur diese Endpunkte benötigt. Behalte nodes/proxy nur für begründete Ausnahmefälle bei und dokumentiere den Owner.

kubectl get clusterroles -o yaml | grep -n 'nodes/proxy' -B 6 -A 10
kubectl get clusterrolebindings -o wide
kubectl get rolebindings -A -o wide
kubectl auth can-i get nodes/proxy --as system:serviceaccount:observability:prometheus
kubectl auth can-i get nodes/metrics --as system:serviceaccount:observability:prometheus

Praktische Kubelet-RBAC-Checkliste

  • Identifiziere alle ClusterRoles mit nodes/proxy und notiere die gebundenen Service-Accounts.
  • Ordne jeden Service-Account einem Anwendungsfall zu, zum Beispiel Prometheus-Scraping, Node-Log-Sammlung, Debugging-Tool oder Plattform-Operator.
  • Ersetze breite Regeln durch gezielte Subresources wie nodes/metrics und nodes/stats, wenn die Komponente nur Metriken liest.
  • Teste nach der Änderung Dashboards, Alert-Regeln, Log-Pipelines und Scrape-Targets, bevor Du die alte Rolle entfernst.
  • Lege für verbleibende nodes/proxy-Rechte ein Ablaufdatum oder einen Review-Termin fest.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: observability-kubelet-read
rules:
- apiGroups: ['']
  resources: ['nodes/metrics', 'nodes/stats']
  verbs: ['get']

Für Teams mit eigenen Metrik-Pipelines sind Monitoring- und Logging-Schulungen eine sinnvolle Ergänzung, wenn Prometheus-Rechte, Log-Sammler und Alerting-Regeln gemeinsam mit RBAC-Änderungen getestet werden.

Kubernetes User-Namespaces aktivieren und Grenzen dokumentieren

Kubernetes User-Namespaces trennen Container-UIDs von Host-UIDs. Dadurch ist ein Prozess, der im Container mit UID 0 läuft, nicht automatisch UID 0 auf dem Node. Für Pods mit User-Namespaces setzt Du in der Pod-Spezifikation hostUsers: false. Prüfe zusätzlich mit kubectl explain pod.spec.hostUsers, wie Deine Cluster-Version das Feld beschreibt.

apiVersion: v1
kind: Pod
metadata:
  name: userns-smoke-test
spec:
  hostUsers: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: registry.example.com/app:1.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ['ALL']

Führe den Rollout nicht nur mit einem Hello-World-Pod durch. Teste repräsentative Workloads mit emptyDir, ConfigMaps, Secrets, CSI-PersistentVolumes, fsGroup, Init-Containern und Sidecars. Achte besonders auf Images, die beim Start chown oder chmod ausführen, feste UIDs erwarten oder Dateien in beschreibbaren Image-Pfaden ablegen.

User-Namespaces sind Defense-in-Depth gegen Container-Escape-Szenarien. Sie ersetzen keine gehärteten Images, kein Least-Privilege-RBAC, keine NetworkPolicies, keine saubere Service-Account-Trennung und keinen vorsichtigen Umgang mit HostPath- oder CSI-Volumes.

MutatingAdmissionPolicy CEL für sicherere Defaults nutzen

MutatingAdmissionPolicy mit CEL eignet sich für einfache, nachvollziehbare Mutationen direkt im API-Server. Damit kannst Du beispielsweise Standardwerte ergänzen, ohne für jede kleine Änderung einen eigenen Mutating-Webhook mit TLS-Zertifikat, Deployment, Service, Verfügbarkeitsregeln und Fehlerbehandlung zu betreiben. Prüfe vor der Nutzung die API-Version und den Reifegrad in Deiner Kubernetes-1.36-Distribution.

Typische Plattform-Regeln sind Default-Labels für Ownership, ein Default-seccompProfile, Namespace-basierte Guardrails und sichere Workload-Defaults für neu erstellte Pods. ValidatingAdmissionPolicy lehnt unerwünschte Spezifikationen ab, Pod Security Admission setzt Pod-Sicherheitsprofile auf Namespace-Ebene durch, und MutatingAdmissionPolicy ergänzt fehlende Felder vor der Validierung.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: default-seccomp
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: ['']
      apiVersions: ['v1']
      operations: ['CREATE']
      resources: ['pods']
  mutations:
  - patchType: ApplyConfiguration
    applyConfiguration:
      expression: >
        Object{spec: Object.spec{securityContext: Object.spec.securityContext{seccompProfile: Object.spec.securityContext.seccompProfile{type: 'RuntimeDefault'}}}}

Ergänze dazu eine MutatingAdmissionPolicyBinding mit Namespace-Selector, zum Beispiel für Namespaces mit dem Label platform.example.com/baseline=restricted. Teste jede Policy mit kubectl apply --dry-run=server und einem repräsentativen Pod-Manifest, bevor Du sie in produktiven Namespaces bindest.

PodSecurityPolicy-Denken aus dem Cluster-Design entfernen

PodSecurityPolicy ist seit Kubernetes v1.25 entfernt. Alte Helm-Values, Runbooks und Audit-Skripte, die noch policy/v1beta1 PodSecurityPolicy referenzieren, beschreiben kein gültiges Sicherheitsmodell für Kubernetes 1.36.

MechanismusAufgabe im Cluster
Pod Security AdmissionNamespace-basierte Pod-Sicherheitslevel wie restricted durchsetzen
ValidatingAdmissionPolicyUnerwünschte API-Objekte mit CEL-Regeln ablehnen
MutatingAdmissionPolicyFehlende sichere Defaults vor der Persistierung ergänzen
OPA Gatekeeper oder KyvernoZusätzliche Policy-Workflows, Reports und organisationsweite Regeln abbilden

Behandle die PSP-Ablösung als Upgrade-Aufgabe. Du aktualisierst nicht nur Binaries, sondern ersetzt veraltete Annahmen in Plattform-Dokumentation, CI-Audits, Helm-Charts und Incident-Runbooks.

EKS-Praxis: EKS Pod Identity Best Practices ohne Secrets

EKS Pod Identity ordnet IAM-Rollen Kubernetes-Service-Accounts zu. Ein Pod erhält temporäre AWS-Zugangsdaten über diese Zuordnung, statt statische AWS-Keys als Umgebungsvariablen oder Kubernetes-Secret im Container zu tragen. Für Teams mit EKS-Plattformen ergänzen Amazon Web Services (AWS) Schulungen die Arbeit an IAM-Rollen, Service-Accounts und Cluster-RBAC.

aws eks list-pod-identity-associations --cluster-name CLUSTERNAME
kubectl get serviceaccounts -A
kubectl get pods -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName
  • Verwende einen eigenen Service-Account pro Workload und Namespace, statt mehrere Anwendungen über denselben Account laufen zu lassen.
  • Beschränke IAM-Policies auf konkrete AWS-APIs und Ressourcen-ARNs, zum Beispiel auf einen S3-Bucket-Prefix oder eine DynamoDB-Tabelle.
  • Prüfe Namespace-Grenzen, damit ein Deployment in dev nicht den Service-Account einer Produktionsanwendung verwendet.
  • Reduziere unnötigen IMDS-Zugriff von Pods, ohne den EKS Pod Identity Agent zu blockieren.
  • Erzwinge per Admission-Policy, dass Workloads mit AWS-Zugriff ein dokumentiertes Owner-Label und einen freigegebenen Service-Account nutzen.

Verbinde Cloud-Identity und Cluster-Identity im selben Review. Ein Kubernetes-RoleBinding, das Deployments ändern darf, entscheidet indirekt darüber, welchen Service-Account und damit welche IAM-Rolle ein Angreifer nach einem Namespace-Kompromiss verwenden könnte.

Manifest-basierte Admission Control vorsichtig testen

Wenn Deine Kubernetes-1.36-Release-Notes manifest-basierte Admission-Konfiguration als Alpha-Feature ausweisen, teste sie nur außerhalb der Produktion. Der API-Server lädt Admission-Konfigurationen dabei vor der Verarbeitung normaler API-Requests; eine fehlerhafte Konfiguration kann deshalb den Start des API-Servers verhindern.

Versioniere die Manifest-Dateien in Git, dokumentiere die verwendeten kube-apiserver-Flags und beschreibe einen Recovery-Pfad. Der Recovery-Pfad sollte enthalten, wie Du ungültige Admission-Manifeste entfernst, den API-Server neu startest und den letzten funktionierenden Stand wiederherstellst.

Deine Kubernetes 1.36 Security Upgrade Checklist

  • Auditiere ClusterRoles, Roles, RoleBindings und ClusterRoleBindings auf breites nodes/proxy.
  • Plane feinere Kubelet-Autorisierung für Monitoring-, Logging- und Observability-Komponenten.
  • Teste Kubernetes User-Namespaces mit repräsentativen Workloads, Init-Containern, Sidecars und Volume-Typen.
  • Führe MutatingAdmissionPolicy CEL für Default-Labels, Default-Security-Contexts und Namespace-Guardrails ein, sofern Deine Distribution die API unterstützt.
  • Entferne PSP-Annahmen aus Dokumentation, Helm-Values, CI-Prüfungen und Runbooks.
  • Prüfe EKS Pod Identity, Kubernetes-Service-Accounts, IAM-Policies und vorhandene Secrets mit AWS-Zugangsdaten.
  • Kontrolliere NetworkPolicies, Image-Härtung, automountServiceAccountToken und Service-Account-Token-Exposition.
  • Rolle Security-Baselines mit Infrastructure as Code aus und vergleiche produktive Cluster regelmäßig gegen Git-Definitionen, um Drift zu erkennen.

Beginne mit einem Read-only-Audit von RBAC, Service-Accounts und Admission-Regeln. Danach testest Du Kubelet-RBAC-Änderungen, User-Namespaces und CEL-Policies in einem Staging-Cluster mit denselben Add-ons, die auch in Produktion laufen.