Ansichten:
Profilanwendbarkeit: Stufe 1
Erlauben Sie nicht generell, dass Container mit dem securityContext.privileged-Flag auf true gesetzt werden.
Privilegierte Container haben Zugriff auf alle Linux-Kernel-Funktionen und -Geräte. Ein Container, der mit vollen Privilegien läuft, kann fast alles tun, was der Host tun kann. Diese Option existiert, um spezielle Anwendungsfälle zu ermöglichen, wie das Manipulieren des Netzwerk-Stacks und den Zugriff auf Geräte.
Es sollte mindestens eine Zugriffssteuerungsrichtlinie definiert sein, die keine privilegierten Container zulässt. Wenn Sie privilegierte Container ausführen müssen, sollte dies in einer separaten Richtlinie definiert werden, und Sie sollten sorgfältig überprüfen, dass nur begrenzte Dienstkonten und Benutzer die Berechtigung erhalten, diese Richtlinie zu verwenden.
Hinweis
Hinweis
Standardmäßig gibt es keine Einschränkungen bei der Erstellung privilegierter Container.

Auswirkung

Pods, die mit spec.containers[].securityContext.privileged: true, spec.initContainers[].securityContext.privileged: true und spec.ephemeralContainers[].securityContext.privileged: true definiert sind, werden nicht erlaubt.

Prüfung

Listen Sie die Richtlinien auf, die für jeden Namespace im Cluster verwendet werden, und stellen Sie sicher, dass jede Richtlinie die Zulassung privilegierter Container verbietet.
Da das manuelle Durchsuchen der Konfigurationen jedes Pods mühsam sein kann, insbesondere in Umgebungen mit vielen Pods, können Sie einen automatisierteren Ansatz mit grep oder anderen Befehlszeilen-Tools verwenden.
Hier ist ein Beispiel, wie Sie dies mit einer Kombination aus kubectl, grep und Shell-Scripting für eine automatisierte Lösung angehen könnten:
kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.containers[].securityContext.privileged == true) | .metadata.name'
Oder:
kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.containers[].securityContext.privileged == true) | select(.metadata.namespace != "kube-system" and .metadata.namespace != "gatekeeper-system" and .metadata.namespace != "azure-arc" and .metadata.namespace != "azure-extensions-usage-system") | "\(.metadata.name) \(.metadata.namespace)"'
Beim Erstellen einer Pod-Sicherheitsrichtlinie sind die ["kube-system", "gatekeeper-system", "azure-arc", "azure-extensions-usage-system"] Namespaces standardmäßig ausgeschlossen.
Dieser Befehl verwendet jq, einen Kommandozeilen-JSON-Prozessor, um die JSON-Ausgabe von kubectl get pods zu analysieren und Pods herauszufiltern, bei denen ein beliebiger Container das securityContext.privileged-Flag auf true gesetzt hat. Bitte beachten Sie, dass Sie den Befehl je nach Ihren spezifischen Anforderungen und der Struktur Ihrer Pod-Spezifikationen anpassen müssen.

Wiederherstellung

Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzer-Workloads enthält, um die Zulassung privilegierter Container zu beschränken.
Um PSA für einen Namespace in Ihrem Cluster zu aktivieren, setzen Sie das pod-security.kubernetes.io/enforce-Label mit dem Richtwert, den Sie durchsetzen möchten:
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
Der obige Befehl erzwingt die eingeschränkte Richtlinie für den NAMESPACE-Namespace.
Sie können auch die Pod-Sicherheitszulassung für alle Ihre Namespaces aktivieren:
kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
Pod-Sicherheitsrichtlinien und Zuweisungen können im Azure-Portal durch die Suche nach Richtlinien gefunden werden. Eine detaillierte Schritt-für-Schritt-Anleitung finden Sie in der Kubernetes-Richtliniendokumentation.