Kubernetes v1.25: Sicherheit für Pods wird zur neuen Norm

Die Veröffentlichung von Kubernetes v1.25 markiert einen bedeutenden Meilenstein für die Sicherheitskontrollen von Pods: Der Pod Security Admission Controller (PSA) hat den Status “stabil” erreicht, während die Pod Security Policy (PSP) entfernt wurde. PSP wurde in Kubernetes v1.21 als veraltet gekennzeichnet und funktioniert in Kubernetes v1.25 und später nicht mehr.

Der Pod Security Admission Controller ersetzt die Pod Security Policy und erleichtert die Durchsetzung vordefinierter Pod Security Standards, indem einfach ein Label zu einem Namespace hinzugefügt wird. Die Pod Security Standards werden von der K8s-Community gepflegt, was bedeutet, dass Sie automatisch aktualisierte Sicherheitsrichtlinien erhalten, wenn neue sicherheitsrelevante Funktionen in Kubernetes eingeführt werden.

Was ändert sich konkret für Entwickler/DevOps-Teams?

Mit der Stabilisierung des Pod Security Admission Controllers wird die Verwaltung der Pod-Sicherheit einfacher und effektiver. Entwickler und DevOps-Teams müssen sich nicht mehr mit der PSP herumschlagen, die nun der Vergangenheit angehört. Stattdessen können sie sich auf die neuen, benutzerfreundlicheren Sicherheitsrichtlinien konzentrieren, die eine bessere Kontrolle darüber bieten, wie Pods innerhalb ihrer Cluster ausgeführt werden.

Praktische Beispiele oder Anwendungsfälle

Verbesserte Verletzungsnachrichten

Die Verletzungsnachrichten wurden verbessert, sodass Sie nun weniger doppelte Nachrichten erhalten. Anstelle einer komplexen Fehlermeldung, wenn die Baseline- und Restricted-Richtlinien dieselbe Fähigkeit überprüfen, sehen Sie jetzt eine vereinfachte Nachricht:

pods “admin-pod” is forbidden: violates PodSecurity “restricted:latest”: unrestricted capabilities (container “admin” must not include “SYS_ADMIN” in securityContext.capabilities.add)

Verbesserte Namespace-Warnungen

Wenn Sie die enforce Pod Security-Labels in einem Namespace ändern, überprüft der Pod Security Admission Controller alle vorhandenen Pods auf Verstöße und zeigt eine Warnung an, wenn es Abweichungen gibt. Diese Warnungen werden jetzt aggregiert für Pods mit identischen Verstößen, was große Namespaces mit vielen Replikaten viel übersichtlicher macht. Ein Beispiel:

Warning: frontend-h23gf2: allowPrivilegeEscalation != false Warning: myjob-g342hj (and 6 other pods): host namespaces, allowPrivilegeEscalation != false Warning: backend-j23h42 (and 1 other pod): non-default capabilities, unrestricted capabilities

Zusätzlich erhalten Sie eine Warnung, wenn Sie ein nicht privilegiertes Label auf einen Namespace anwenden, der von der Durchsetzung ausgeschlossen ist:

Warning: namespace ‘kube-system’ is exempt from Pod Security, and the policy (enforce=baseline:latest) will be ignored

Änderungen an den Pod Security Standards

Die Pod Security Standards, die der Pod Security Admission durchsetzt, wurden mit Unterstützung für das neue Pod OS-Feld aktualisiert. In v1.25 und später sind bestimmte Linux-spezifische Einschränkungen nicht mehr erforderlich, wenn Sie das Feld .spec.os.name des Pods explizit auf windows setzen:

• Seccomp - Das Feld seccompProfile.type für Pod- und Container-Sicherheitskontexte
• Privilegierte Eskalation - Das Feld allowPrivilegeEscalation auf Container-Sicherheitskontexten
• Fähigkeiten - Die Anforderung, alle Fähigkeiten im Feld capabilities auf Containern zu verwerfen

In Kubernetes v1.23 und früher hat der Kubelet das Pod OS-Feld nicht durchgesetzt. Wenn Ihr Cluster Knoten mit einem Kubelet der Version v1.23 oder älter enthält, sollten Sie die Restricted-Richtlinien festlegen auf eine Version vor v1.25.

Die Zusammenarbeit mit Partnern wie ayedo kann Ihnen helfen, bei der Implementierung dieser neuen Sicherheitsstandards bestmöglich unterstützt zu werden und Ihre Kubernetes-Umgebung sicher zu gestalten.

Quelle: Kubernetes Blog