Migration von Pod-Sicherheitsrichtlinien: Ein umfassender Leitfaden (Teil 1: Übergang zu PSA)

Einführung

Da sich Kubernetes immer weiter zur führenden Container-Orchestrierungsplattform entwickelt, bleibt die Sicherheit ein vorrangiges Anliegen für Unternehmen, die containerisierte Anwendungen bereitstellen. Unter den grundlegenden Tools im Sicherheitsarsenal von Kubernetes spielten Pod Security Policies (PSP) einst eine zentrale Rolle. PSP ermöglichte es Administratoren, Sicherheitsbeschränkungen für Pods sorgfältig zu definieren und durchzusetzen, um sicherzustellen, dass nur Container, die bestimmte Sicherheitsstandards erfüllen, innerhalb des Clusters betrieben werden konnten.

Die Landschaft der Kubernetes-Sicherheit entwickelt sich jedoch schnell weiter, und es ist wichtig zu beachten, dass PSP nun veraltet ist, beginnend mit Kubernetes 1.25 (siehe Link zu den dringenden Versionshinweisen zu Kubernetes 1.25). Diese Änderung ist auf verschiedene Faktoren zurückzuführen, darunter die Komplexität der Verwaltung und Pflege von PSP-Richtlinien, was häufig zu betrieblichen Herausforderungen für Benutzer führt.

Als Reaktion auf die Abschaffung suchen Unternehmen nun nach modernen Alternativen zu PSP, die nicht nur Sicherheitsanforderungen erfüllen, sondern auch den Prozess der Sicherung von Arbeitslasten in Kubernetes rationalisieren.

In diesem umfassenden Leitfaden begeben wir uns auf eine Reise, um diesen Wandel in den Sicherheitspraktiken von Kubernetes zu bewältigen, wobei wir uns auf den Übergang zur Pod Security Admission (PSA) konzentrieren. PSA ist eine der robustesten verfügbaren Alternativen und wird in diesem Artikel ausführlich untersucht. Es ist jedoch erwähnenswert, dass zwei weitere Alternativen, Kyverno und OPA Gatekeeper, in separaten Artikeln dieser Serie behandelt werden.

In diesem Artikel finden Sie detaillierte Anweisungen zum Einrichten und Installieren von PSA, Schritt-für-Schritt-Migrationsanleitungen für einen reibungslosen Übergang von PSP zu PSA und präzise Befehle zum Übertragen vorhandener PSP-Regeln zu PSA. Darüber hinaus erwerben Sie das Wissen, Namensräume mithilfe von auf PSA zugeschnittenen Probelaufbefehlen auf ihre Migrationsbereitschaft zu prüfen.

Am Ende dieses Leitfadens erhalten Sie ein umfassendes Verständnis der Stärken und Grenzen von PSA und können so eine fundierte Entscheidung auf der Grundlage der spezifischen Sicherheitsanforderungen Ihres Unternehmens und der Kubernetes-Umgebung treffen.

Mit diesem Leitfaden können Sie Ihre Kubernetes-Sicherheitspraktiken getrost modernisieren und sicherstellen, dass Ihre Workloads geschützt bleiben, während Sie sich von der Ära der Pod-Sicherheitsrichtlinien verabschieden.

Pod Security Admission (PSA)

• PSA setzt Kubernetes-Sicherheitsstandards durch: PSA stellt sicher, dass Container den nativen Sicherheitsstandards von Kubernetes entsprechen, die in den Pod-Sicherheitsstandards definiert sind. Diese Standards klassifizieren Sicherheitsrichtlinien in drei verschiedene Profile mit jeweils unterschiedlichem Maß an Restriktion:

  
  

  • Privileged : Die Privileged-Richtlinie ist bewusst offen und völlig uneingeschränkt. Typischerweise zielt diese Richtlinie auf Workloads auf System- und Infrastrukturebene ab, die von vertrauenswürdigen Benutzern verwaltet werden. Es zeichnet sich durch das Fehlen von Einschränkungen aus. Während standardmäßig zugelassene Mechanismen wie Gatekeeper von Natur aus privilegiert sein können, sollte die privilegierte Richtlinie bei standardmäßig verweigernden Mechanismen wie der Pod Security Policy (PSP) alle Einschränkungen deaktivieren.

  • Baseline : Die Baseline-Richtlinie ist für die einfache Übernahme durch gängige Container-Workloads konzipiert und verhindert gleichzeitig bekannte Rechteausweitungen. Es richtet sich an Anwendungsbetreiber und Entwickler unkritischer Anwendungen.

  • Eingeschränkt : Die Richtlinie „Eingeschränkt“ konzentriert sich auf die Durchsetzung strenger Best Practices für die Pod-Härtung, allerdings möglicherweise auf Kosten einer gewissen Kompatibilität. Es richtet sich in erster Linie an Betreiber und Entwickler sicherheitskritischer Anwendungen sowie an Benutzer mit geringerem Vertrauen. Eine umfassende Liste der Kontrollen, die für jedes Profil erzwungen oder nicht zugelassen werden sollten, finden Sie in der offiziellen Dokumentation.

    
    

• Keine direkte PSP-Regelübertragung: Im Gegensatz zu einigen anderen Lösungen bietet PSA keine einfache Methode zur direkten Migration oder Änderung von Pod Security Policy (PSP)-Regeln. Das Hauptaugenmerk von PSA liegt auf der Validierung von Pods anhand der etablierten Kubernetes-Sicherheitsstandards , einschließlich der oben genannten Profile.

• Keine Mutationen : Während PSA bei der Validierung wirksam ist, kann es die Pod-Spezifikationen nicht ändern oder anpassen, wie dies bei PSP der Fall wäre. Der Hauptzweck von PSA besteht darin, vordefinierte Kubernetes-Sicherheitsstandards durchzusetzen und enthält keine Funktionen zum Ändern oder Mutieren von Pod-Spezifikationen. Der Schwerpunkt liegt auf der Validierung von Pods anhand dieser etablierten Standards.

Einrichtung und Installation

Da es sich bei PSA um eine native Kubernetes-Komponente handelt, müssen Sie nur sicherstellen, dass der PSA-Controller (Pod Security Admission) in Ihrem Kubernetes-Cluster aktiviert ist, damit es funktioniert. Sie können dies tun, indem Sie den folgenden Befehl ausführen:

kubectl api-versions | grep admission

Vorbereitungsschritte für die Migration

Bewerten Sie Namespace-Berechtigungen

Die Steuerung der Pod-Sicherheitszulassung wird durch Namespace-Labels beeinflusst. Dies bedeutet, dass Personen mit der Berechtigung zum Aktualisieren, Patchen oder Erstellen von Namespaces auch die Berechtigung haben, die Pod-Sicherheitseinstellungen für diese Namespaces zu ändern. Diese Änderung könnte möglicherweise strengere Sicherheitsrichtlinien umgehen. Bevor Sie fortfahren, müssen Sie unbedingt überprüfen, dass Namespace-Berechtigungen ausschließlich vertrauenswürdigen und privilegierten Benutzern zugewiesen werden. Es wird empfohlen, diese erhöhten Berechtigungen nicht Benutzern zu gewähren, die keinen solchen Zugriff benötigen. Wenn zusätzliche Einschränkungen für die Konfiguration von Pod-Sicherheitsbezeichnungen für Namespace-Objekte erforderlich sind, sollten Sie die Verwendung eines Zulassungs-Webhooks in Betracht ziehen, um diese Einschränkungen durchzusetzen.

Optimieren und normalisieren Sie PodSecurityPolicies

Vor der Migration zu Pod Security Admission (PSA) ist es von Vorteil, Ihre PodSecurityPolicies (PSP) zu normalisieren:

• Nicht unterstützte Felder entfernen : Eliminieren Sie Optionen, die nicht durch die Pod-Sicherheitsstandards abgedeckt sind. Zu diesen Optionen gehören:

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• Eliminieren Sie rein mutierende Felder : Starten Sie den Prozess, indem Sie Felder entfernen, die lediglich eine mutierende Wirkung haben und keinen Einfluss auf die Validierungsrichtlinie haben. Zu diesen Feldern gehören, wie auch in der Referenz „Zuordnung von PodSecurityPolicies zu Pod-Sicherheitsstandards“ erwähnt:

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

Bestimmen Sie die geeignete Pod-Sicherheitsstufe

Bei der Bestimmung der geeigneten Pod-Sicherheitsstufe für Ihren Namespace müssen Sie mehrere Methoden berücksichtigen:

Nach Sicherheitsanforderungen für den Namespace

Wenn Sie mit der erwarteten Zugriffsebene und den Sicherheitsanforderungen für den Namespace vertraut sind, können Sie basierend auf diesen spezifischen Anforderungen eine geeignete Pod-Sicherheitsebene auswählen. Dieser Ansatz ähnelt dem Ansatz für Sicherheitseinstellungen in einem neuen Cluster.

Durch vorhandene PodSecurityPolicies:

Nutzen Sie die Referenz „Zuordnung von PodSecurityPolicies zu Pod-Sicherheitsstandards“ , um jede Ihrer vorhandenen Pod-Sicherheitsrichtlinien (PSPs) einer entsprechenden Pod-Sicherheitsstandardstufe zuzuordnen.
Wenn Ihre PSPs ursprünglich nicht auf den Pod-Sicherheitsstandards basieren, müssen Sie möglicherweise eine Entscheidung treffen. Wählen Sie eine Pod-Sicherheitsstufe, die mindestens so freizügig ist wie die Ihrer PSPs, oder entscheiden Sie sich für eine Stufe, die mindestens genauso restriktiv ist. Um zu ermitteln, welche PSPs für Pods innerhalb eines bestimmten Namespace verwendet werden, verwenden Sie den folgenden Befehl:

 kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u

Nach vorhandenen Pods:

Führen Sie einen Probelauf durch und wenden Sie den Label-Befehl aus dem nächsten Abschnitt an, um sowohl die Basis- als auch die eingeschränkte Pod-Sicherheitsstufe zu testen. Dies hilft Ihnen zu beurteilen, ob diese Ebenen für Ihre bestehenden Arbeitslasten ausreichend freizügig sind. Wählen Sie die gültige Ebene mit den geringsten Privilegien, die zu Ihren vorhandenen Arbeitslasten passt.

Testen der Pod-Sicherheitsstufe

Nachdem Sie die Pod-Sicherheitsstufe für Ihren Namespace festgelegt haben (mit Ausnahme der privilegierten Stufe), ist es wichtig, die ausgewählte Richtlinie zu validieren. Pod Security bietet Testmöglichkeiten, um einen reibungslosen Rollout und die Einhaltung von Sicherheitsstandards zu gewährleisten.

Trockenlauftest:

Verwenden Sie diese Methode, um die Auswirkungen der ausgewählten Richtlinie ohne sofortige Durchsetzung zu bewerten.
Um einen Probelauf durchzuführen, verwenden Sie den folgenden Befehl, der alle vorhandenen Pods hervorhebt, die die angegebene Richtlinienstufe nicht erfüllen:

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

Prüfung des Audit-Modus:

Im Audit-Modus können Sie Richtlinienverstöße aufzeichnen, ohne sie durchzusetzen. Verstoßende Pods werden zur späteren Überprüfung in den Prüfdatensätzen protokolliert. Aktivieren Sie den Überwachungsmodus mit dem folgenden Befehl:

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

Wenn beim Testen unerwartete Richtlinienverstöße auftreten, können Sie:

• Aktualisieren Sie nicht konforme Workloads, um sie an die Richtlinie anzupassen.
• Passen Sie bei Bedarf die Pod-Sicherheitsstufe für den Namespace an, um Ihren Arbeitslastanforderungen gerecht zu werden.

Durchsetzung der Pod-Sicherheitsstufe

Sobald Sie sicher sind, dass die ausgewählte Pod-Sicherheitsstufe für Ihren Namespace geeignet ist, können Sie mit der Durchsetzung fortfahren. Dieser Schritt stellt sicher, dass die gewünschten Sicherheitsstandards aktiv auf Ihre Workloads innerhalb des Namespace angewendet werden.

Um die gewünschte Pod-Sicherheitsstufe für den Namespace zu erzwingen, verwenden Sie den folgenden Befehl:

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

Durch die Ausführung dieses Befehls wird die angegebene Pod-Sicherheitsstufe aktiviert und erzwungen, wodurch die Sicherheitslage Ihres Namespace verbessert wird.

PSP umgehen

Um PodSecurityPolicy auf Namespace-Ebene effektiv zu umgehen, können Sie eine vollständig privilegierte Pod-Sicherheitsrichtlinie (PSP) an alle Dienstkonten im Namespace binden. Durch diesen Prozess wird sichergestellt, dass Pods innerhalb des Namespace keinen Änderungen oder Einschränkungen mehr unterliegen, die von PodSecurityPolicy auferlegt werden. Sie können dies auf Clusterebene oder auf Ebene einzelner Namespaces tun.

Clusterbezogene Einrichtung (nur einmal für den gesamten Cluster erforderlich):

Erstellen Sie eine vollständig privilegierte Pod-Sicherheitsrichtlinie (PSP), indem Sie eine YAML-Konfigurationsdatei anwenden, z. B.privileged-psp.yaml . Dieser PSP sollte Pods alle erforderlichen Berechtigungen gewähren und eine Clusterrolle mit dem Namen „privileged-psp“ erstellen, um die Verwendung von Pod-Sicherheitsrichtlinien (PSPs) zu ermöglichen und sie dem privilegierten PSP zuzuordnen:

 kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

Deaktivierung pro Namespace:

Erstellen Sie eine Rollenbindung im Ziel-Namespace, um die Clusterrolle „privileged-psp“ der Gruppe system:serviceaccounts:$NAMESPACE zuzuordnen. Diese Bindung gewährt effektiv allen Dienstkonten innerhalb des Namespace Zugriff auf den vollständig privilegierten PSP und umgeht PodSecurityPolicy:

 kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

Bei diesem Setup ist der privilegierte PSP nicht mutierend und der PodSecurityPolicy-Zulassungscontroller priorisiert immer nicht mutierende PSPs. Infolgedessen werden Pods in diesem Namespace nicht mehr durch PodSecurityPolicy geändert oder eingeschränkt.

Ein Vorteil dieses Ansatzes ist seine Reversibilität. Wenn Probleme auftreten, können Sie die Änderung problemlos rückgängig machen, indem Sie das RoleBinding löschen, das mit der Deaktivierung von PodSecurityPolicy verbunden ist. Stellen Sie sicher, dass während dieses Vorgangs bereits vorhandene Pod-Sicherheitsrichtlinien bestehen bleiben.

PodSecurityPolicy-Deaktivierung rückgängig machen:

Um die PodSecurityPolicy-Deaktivierung für den Namespace rückgängig zu machen, löschen Sie einfach das zuvor erstellte RoleBinding:

 kubectl delete -n $NAMESPACE rolebinding disable-psp

Sehen Sie sich die Prozesse zur Erstellung von Namespaces noch einmal an

Da bestehende Namespaces aktualisiert werden, um die Pod-Sicherheitszulassung zu erzwingen, ist es wichtig, Ihre Prozesse und Richtlinien zum Erstellen neuer Namespaces zu überprüfen und zu aktualisieren. Dadurch wird sichergestellt, dass neue Namespaces von Anfang an mit einem geeigneten Pod-Sicherheitsprofil konfiguriert werden.
Berücksichtigen Sie die folgenden Schritte, um die Prozesse zur Erstellung von Namespaces zu verbessern:

1. Passen Sie die Richtlinien zur Erstellung von Namespaces an : Aktualisieren Sie die Richtlinien und Verfahren Ihrer Organisation zum Erstellen neuer Namespaces, um die Auswahl und Anwendung der gewünschten Pod-Sicherheitsstufe einzubeziehen. Stellen Sie sicher, dass Sicherheitsstandards bereits in der Erstellungsphase festgelegt sind.

2. Statische Konfiguration: Sie können den Pod Security-Zulassungscontroller statisch konfigurieren, um standardmäßige Durchsetzungs-, Überwachungs- und/oder Warnstufen für unbeschriftete Namespaces zu definieren. Dieser Ansatz stellt sicher, dass Namespaces ohne explizite Pod-Sicherheitsbezeichnungen weiterhin standardmäßig Ihren angegebenen Sicherheitsstandards entsprechen.

   
   

   Durch die Überarbeitung Ihrer Namespace-Erstellungsprozesse können Sie Pod-Sicherheitsstandards nahtlos in Ihre Kubernetes-Umgebung integrieren und einen konsistenten und sicheren Ansatz für alle alten und neuen Namespaces beibehalten.

Deaktivieren Sie PodSecurityPolicy

Sobald Sie sicher sind, dass der PodSecurityPolicy (PSP)-Zulassungscontroller nicht mehr benötigt wird und dass die Pod Security Admission (PSA) erfolgreich implementiert und validiert wurde, können Sie mit der Deaktivierung des PSP-Zulassungscontrollers fortfahren.

Hier sind die Schritte zum Deaktivieren des PSP-Zulassungscontrollers:

Ändern Sie die kube-apiserver-Konfiguration:

• Öffnen Sie die Konfigurationsdatei für Ihren kube-apiserver, die sich normalerweise unter /etc/kubernetes/manifests/kube-apiserver.yaml.
• Fügen Sie das Flag --disable-admission-plugins hinzu, um den PSP-Zulassungscontroller zu deaktivieren. Stellen Sie sicher, dass es aus der Liste der aktiven Zulassungs-Plugins entfernt wird.

 kube-apiserver --disable-admission-plugins=PodSecurityPolicy

• Speichern Sie die Konfigurationsdatei.

Kube-Apiserver neu starten:

• Starten Sie den kube-apiserver neu, um die Änderungen zu übernehmen. Normalerweise können Sie dies erreichen, indem Sie die Kubernetes-Steuerungsebene oder den Kube-Apiserver-Pod selbst neu starten.

 systemctl restart kubelet

Überprüfung:

• Stellen Sie sicher, dass der PSP-Zulassungscontroller deaktiviert ist, indem Sie die kube-apiserver-Protokolle oder seinen Status überprüfen.

Fahren Sie nach ausreichender Einwirkzeit mit dem nächsten Schritt fort, um sicherzustellen, dass Sie nicht auf PSPs zurückgreifen müssen.

PSP-Ressourcen bereinigen:

Wenn der PSP-Zulassungscontroller deaktiviert und PSA vorhanden ist, können Sie Ihre vorhandenen PodSecurityPolicies sowie alle zugehörigen Rollen, ClusterRoles, RoleBindings und ClusterRoleBindings sicher löschen.

 kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true

Dieser Bereinigungsschritt stellt sicher, dass in Ihrem Cluster keine verbleibenden PSP-Konfigurationen vorhanden sind.

Indem Sie den PSP-Zulassungscontroller deaktivieren und PSP-bezogene Ressourcen eliminieren, vereinfachen Sie die Sicherheitsarchitektur Ihres Clusters und schließen den Übergang zur Pod-Sicherheitszulassung ab.

Zusammenfassung

In diesem umfassenden Leitfaden haben wir die wesentlichen Schritte und Überlegungen für einen reibungslosen Übergang des Sicherheits-Frameworks Ihres Kubernetes-Clusters von Pod Security Policies (PSP) zu Pod Security Admission (PSA) untersucht. Diese Migration stellt sicher, dass Ihre Workloads weiterhin sicher laufen und gleichzeitig an den sich weiterentwickelnden Sicherheitsstandards von Kubernetes ausgerichtet sind.

Vor- und Nachteile der Verwendung von Pod Security Admission (PSA)

Vorteile:

• Native Kubernetes-Komponente : PSA ist ein integraler Bestandteil von Kubernetes, sodass keine Toolinstallationen von Drittanbietern erforderlich sind. Es nutzt die integrierten Sicherheitsfunktionen der Plattform.
• Setzt Kubernetes-Standards durch : PSA orientiert sich an den nativen Sicherheitsstandards von Kubernetes und stellt so die Einhaltung der Best Practices der Plattform sicher.

Nachteile:

• Eingeschränkte Anpassung : PSA bietet möglicherweise nicht den gleichen Grad an Anpassung wie PSP, insbesondere für komplexe Sicherheitsrichtlinien, die eine Änderung der Pod-Spezifikationen erfordern.
• Nachrüstung erforderlich : Vorhandene Workloads müssen aktualisiert werden, um Sicherheitskontexteinstellungen einzuschließen, was möglicherweise eine Änderung der YAML-Dateien erfordert.

Dieser Leitfaden vermittelt Ihnen das Wissen und die Schritte, die für eine sichere Migration von PSP zu PSA erforderlich sind, um einen sicheren und effizienten Übergang zu gewährleisten und gleichzeitig Ihre Kubernetes-Workloads zu schützen. Seien Sie gespannt auf kommende Artikel, in denen ich alternative Migrationspfade zu Kyverno und OPA Gatekeeper erkunden werde.