Ansichten:
Profilanwendbarkeit: Stufe 1
Erlauben Sie generell nicht, dass Container mit dem securityContext.privileged-Flag auf true gesetzt ausgeführt 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 werden, die privilegierte Container nicht zulässt. Wenn Sie privilegierte Container ausführen müssen, sollte dies in einer separaten Richtlinie definiert werden, und Sie sollten sorgfältig prüfen, um sicherzustellen, 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 zugelassen.

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 von privilegierten Containern verbietet.
Da das manuelle Durchsuchen der Konfiguration 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'
OR
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 werden ["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 Container das securityContext.privileged-Flag auf true gesetzt hat.
Hinweis
Hinweis
Möglicherweise müssen Sie den Befehl anpassen, je nach Ihren spezifischen Anforderungen und der Struktur Ihrer Pod-Spezifikationen.

Wiederherstellung

Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerarbeitslasten 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. Zum Beispiel:
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 hier: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/policy-for-kubernetes