Wenn Sie Pod-Sicherheitsrichtlinien aktivieren, achten Sie darauf, dass manipulierte Namespaces (außer istio-system
) die Sicherheit anderer Namespaces, die sich die gleichen Knoten teilen, nicht beeinträchtigen. Beispiel-PodSecurityPolicy
-Ressourcendateien, die mit Mesh-CA funktionieren, werden mit Anthos Service Mesh bereitgestellt. Sie können diese Dateien bei Bedarf ändern. Im Folgenden wenden Sie zuerst die Pod-Sicherheitsrichtlinien an und aktivieren dann die Pod-Sicherheitsrichtlinie für den GKE-Cluster.
Pod-Sicherheitsrichtlinien aktivieren
Prüfen Sie, ob Ihr System bereits Pod-Sicherheitsrichtlinien definiert hat:
kubectl get psp --all-namespaces
Wenn der Befehl eine Liste der vorhandenen Richtlinien zurückgibt, werden in Ihrem System bereits Pod-Sicherheitsrichtlinien angewendet. Wir empfehlen die Verwendung Ihrer vorhandenen YAML-Dateien für
PodSecurityPolicy
, falls Sie ein rollback durchführen müssen. Sie müssen den folgenden Abschnitt in jeder vorhandenen Pod-Sicherheitsrichtlinien zum Abschnittspec
hinzufügen, mit Ausnahme der Richtlinien, die mitgce
beginnen.allowedHostPaths: - pathPrefix: "/var/run/sds" readOnly: true allowedCapabilities: - NET_ADMIN - NET_RAW
Diese Zeilen ermöglichen das Lesen aus dem Hostpfad
/var/run/sds
und ermöglichen das automatische Einfügen der Sidecar-Datei.Mit
kubectl
können Sie die Pod-Sicherheitsrichtlinien in Kubernetes bearbeiten und anwenden:kubectl edit psp YOUR_EXISTING_POD_SECURITY_POLICY
Wenn der Befehl
No resources found
zurückgibt, ist keine Pod-Sicherheitsrichtlinie definiert. Möglicherweise müssen Sie die Dateisamples/security/psp/all-pods-psp.yaml
trotzdem ändern, um sicherzustellen, dass sie nicht mit Ihren vorhandenen Arbeitslasten in Konflikt steht. Weitere Informationen finden Sie im Leitfaden zur Pod-Sicherheitsrichtlinie. Wenden Sie nach dem Ändern der Datei die Anwendung an:kubectl apply -f "samples/security/psp/all-pods-psp.yaml"
Wenden Sie die Pod-Sicherheitsrichtlinie an, um den Secret Discovery Service (SDS) zu schützen:
kubectl apply -f "samples/security/psp/citadel-agent-psp.yaml"
Dadurch erhält der Citadel-Agent (auch Knoten-Agent genannt) die Berechtigung, den UDS-Pfad
/var/run/sds
auf der Host-VM zu erstellen.Führen Sie den folgenden Befehl aus, um die Pod-Sicherheitsrichtlinie zu aktivieren:
gcloud beta container clusters update ${CLUSTER_NAME} \ --enable-pod-security-policy
Das Aktivieren der Pod-Sicherheitsrichtlinien kann einige Minuten dauern. Bestehende Arbeitslasten können während dieses Vorgangs keine Verbindung zum Kubernetes-Master herstellen. Warten Sie, bis der Kubernetes-Master wieder einsatzbereit ist. Sie können den Clusterstatus in der Google Cloud Console auf der Seite "Kubernetes-Cluster" prüfen.
Weitere Informationen finden Sie unter Pod-Sicherheitsrichtlinien verwenden.
Pod-Sicherheitsrichtlinien überprüfen
Wenn Sie bereits Arbeitslasten haben, sollten Sie überprüfen, ob die Arbeitslasten mit den neuen Pod-Sicherheitsrichtlinien bereitgestellt werden können.
Wählen Sie Deployments aus, die Sie überprüfen und deren Replikate erhöhen möchten. Wenn der angegebene Dienst beispielsweise ein Replikat hat, erhöhen Sie es um 1:
kubectl scale deployment YOUR_DEPLOYMENT --replicas=2 -n YOUR_NAMESPACE
Prüfen Sie, ob die Bereitstellung hochskaliert wird:
kubectl get deploy
Prüfen Sie, ob die neue Arbeitslast bereitgestellt werden kann. Das bedeutet, dass die Pod-Sicherheitsrichtlinie keinen Einfluss auf die Bereitstellung einer Arbeitslast für den Dienst hat.
kubectl get deployment YOUR_SERVICE -n YOUR_NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE YOUR_SERVICE 2/2 2 2 ...
Skalieren Sie die Replikate des Dienstes herunter:
kubectl scale deployment YOUR_SERVICE --replicas=1 -n YOUR_NAMESPACE
Wenn Ihre Arbeitslasten nicht bereitgestellt werden, können Sie die Pod-Sicherheitsrichtlinie vorübergehend deaktivieren, während Sie die YAML-Dateien korrigieren:
gcloud beta container clusters update ${CLUSTER_NAME} \ --no-enable-pod-security-policy