PCI-DSS v3.2.1-Richtlinieneinschränkungen verwenden

Achtung: Das Richtlinien-Bundle von PCI-DSS v3.2.1 wurde verworfen. Migrieren Sie zum PCI DSS v4.0-Richtlinien-Bundle.

Policy Controller enthält eine Standardbibliothek mit Einschränkungsvorlagen, die mit dem PCI-DSS v3.2.1-Bundle verwendet werden können, um die Compliance Ihrer Clusterressourcen mit einigen Aspekten des Payment Card Industry Data Security Standard (PCI-DSS) v3.2.1 zu bewerten.

Einschränkungen für das PCI-DSS v3.2.1-Richtlinien-Bundle

Name der Einschränkung	Beschreibung der Einschränkung	Einstellungs-ID	Profil
pci-dss-v3.2.1-resources-have-required-labels	Sicherstellen, dass die Anforderungen für eine Firewall erfüllt sind, da alle Anwendungen ein bestimmtes Label enthalten müssen.	1.1.4	Standard
pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations	Sicherstellen der Anforderungen für Netzwerksteuerungen, da alle Anwendungen eine bestimmte Annotation enthalten müssen.	1.1.5, 2.4	Standard
pci-dss-v3.2.1-require-default-deny-network-policies	Erfordert, dass jeder im Cluster definierte Namespace eine standardmäßige Ablehnung NetworkPolicy für ausgehenden Traffic hat.	1.2, 1.3, 2.2.2	Erweitert
pci-dss-v3.2.1-block-all-ingress	Schränkt die Erstellung von Ingress-Objekten ein.	1.2, 1.3	Erweitert
pci-dss-v3.2.1-require-valid-network-ranges	Schränkt die CIDR-Bereiche ein, die für eingehenden und ausgehenden Traffic verwendet werden können.	1.2, 1.3.2	Erweitert
pci-dss-v3.2.1-require-namespace-network-policies	Erfordert, dass jeder im Cluster definierte Namespace eine NetworkPolicy hat.	1.2	Standard
pci-dss-v3.2.1-enforce-managed-by-configmanagement-label	Erfordert ein gültiges app.kubernetes.io/managed-by=-Label für RoleBinding-Ressourcen.	1.2.2, 8.1.2	Standard
pci-dss-v3.2.1-block-creation-with-default-serviceaccount	Schränkt das Erstellen von Ressourcen mit einem Standarddienstkonto ein.	2.1	Standard
pci-dss-v3.2.1-restrict-default-namespace	Schränkt die Verwendung des Standard-Namespace durch Pods ein.	2.1	Standard
pci-dss-v3.2.1-asm-peer-authn-strict-mtls	Erzwingen Sie, dass alle PeerAuthentications keine strikten mMTLS überschreiben können.	4.1	Standard
pci-dss-v3.2.1-require-av-daemonset	Erfordert das Vorhandensein eines Antiviren-Daemonsets.	5.1.1, 5.3	Standard
pci-dss-v3.2.1-enforce-config-management	Vorhandensein und Aktivierung von Config Sync erzwingen.	5.3, 6.1, 6.4	Standard
pci-dss-v3.2.1-enforce-cloudarmor-backendconfig	Erzwingen Sie die Cloud Armor-Konfiguration für BackendConfig-Ressourcen.	6.5, 6.6	Standard
pci-dss-v3.2.1-restrict-rbac-subjects	Schränkt die Verwendung von Namen in RBAC auf zulässige Werte ein.	8.1, 8.1.5	Erweitert
pci-dss-v3.2.1-block-secrets-of-type-basic-auth	Schränkt die Verwendung von Secrets vom Typ „basic-auth“ ein.	8.1.5, 8.2.3, 8.5	Standard
pci-dss-v3.2.1-nodes-have-consistent-time	Sorgt für eine konsistente und korrekte Zeit auf Knoten, indem die Verwendung von COS als Betriebssystem-Image sichergestellt wird.	10.4.1, 10.4.3	Standard

Standardeinschränkungen im Vergleich zu erweiterten Bundle-Einschränkungen

Das PCI DSS v3.2.1-Bundle implementiert bestimmte Richtlinienanforderungen, um einige Aspekte der PCI DSS v3.2.1-Steuerelemente zu erfüllen. Neben der Anpassung Ihrer Arbeitslast an die Anforderungen des Standard-Bundles können Sie auch ein optionales Set von erweiterten Einschränkungen verwenden, die eine Anpassung an Ihre Umgebung erfordern.

Hinweise

1. Installieren und initialisieren Sie das Google Cloud CLI, das die in dieser Anleitung verwendeten Befehle gcloud und kubectl enthält. Wenn Sie Cloud Shell verwenden, ist Google Cloud CLI vorinstalliert.
2. Installieren Sie Policy Controller v1.14.3 oder höher in Ihrem Cluster mit der Standardbibliothek der Einschränkungsvorlagen. Sie müssen auch die Unterstützung für referenzielle Einschränkungen aktivieren, da dieses Bundle referenzielle Einschränkungen enthält.

Policy Controller für referenzielle Einschränkungen konfigurieren

Warnung: Sie können eigene Änderungen überschreiben. Wenn Sie bereits einen Config im Namespace gatekeeper-system haben, müssen Sie alle vorherigen Anpassungseinstellungen einschließen, um Ihre Änderungen beizubehalten.

1. Speichern Sie das folgende YAML-Manifest in einer Datei als policycontroller-config.yaml. Das Manifest konfiguriert Policy Controller so, dass bestimmte Arten von Objekten beobachtet werden.

   apiVersion: config.gatekeeper.sh/v1alpha1
   kind: Config
   metadata:
     name: config
     namespace: "gatekeeper-system"
   spec:
     sync:
       syncOnly:
         - group: "apps"
           version: "v1"
           kind: "DaemonSet"
         - group: "networking.k8s.io"
           version: "v1"
           kind: "NetworkPolicy"
   

2. Wenden Sie das policycontroller-config.yaml-Manifest an:

   kubectl apply -f policycontroller-config.yaml
   

Arbeitslast Ihres Clusters für PCI-DSS v3.2.1 konfigurieren

Standardset

1. Alle Anwendungen (ReplicaSet, Deployment, StatefulSet und DaemonSet) müssen eine pci-dss-firewall-audit label mit dem Schema pci-dss-[0-9]{4}q[1-4] enthalten.
2. Alle Anwendungen (ReplicaSet, Deployment, StatefulSet, DaemonSet) müssen eine network-controls/date-Anmerkung mit dem Schema YYYY-MM-DD enthalten.
3. Jeder im Cluster definierte namespace muss eine NetworkPolicy haben.
4. Die Verwendung von Config Sync für configmanagement.gke.io ist standardmäßig erforderlich. Die zulässigen app.kubernetes.io/managed-by-Werte können jedoch in der Einschränkung pci-dss-v3.2.1-enforce-managed-by-configmanagement-label angepasst werden.
5. Ressourcen können nicht mit dem Standarddienstkonto erstellt werden.
6. Der Standard-namespace kann nicht für Pods verwendet werden.
7. Wenn Sie Anthos Service Mesh verwenden, muss ASM PeerAuthentication die strikte mTLS-spec.mtls.mode: STRICT verwenden.
8. Eine Antivirenlösung ist erforderlich. Die Standardeinstellung ist das Vorhandensein eines daemonset namens clamav in pci-dss-av namespace. Der Name und der Namespace von daemonset können jedoch an Ihre Implementierung in der pci-dss-v3.2.1-require-av-daemonset-Einschränkung angepasst werden.
9. Das Vorhandensein und Aktivieren von Config Sync ist erforderlich.
10. Alle BackendConfig müssen für CloudArmor konfiguriert sein.
11. Die Verwendung von Secrets vom Typ basic-auth ist nicht zulässig.
12. Alle Knoten müssen für eine konstante Zeit für ihr Image Container-Optimized OS von Google verwenden.

Erweitertes Paket (optional, Anpassung erforderlich)

1. Jeder namespace, der im Cluster definiert ist, hat eine standardmäßige Ablehnungs-NetworkPolicy für ausgehenden Traffic. Zulässige Ausnahmen können in pci-dss-v3.2.1-require-namespace-network-policies spezifisch sein.
2. Nur zulässige Ingress-Objekte (Ingress-, Gateway- und Service-Typen von NodePort und LoadBalancer) können erstellt werden. Diese können in pci-dss-v3.2.1-block-all-ingress angegeben werden.
3. Für Ingress und Express können nur zulässige IP-Bereiche verwendet werden, diese können in pci-dss-v3.2.1-require-valid-network-ranges angegeben werden.
4. Nur zulässige Subjekte können in RBAC-Bindungen verwendet werden. Ihre Domainnamen können in pci-dss-v3.2.1-restrict-rbac-subjects angegeben werden.

PCI-DSS v3.2.1-Richtlinien-Bundle prüfen

Mit Policy Controller können Sie Richtlinien für Ihren Kubernetes-Cluster erzwingen. Damit Sie Ihre Arbeitslasten und deren Compliance in Bezug auf die in der vorherigen Tabelle beschriebenen PCI-DSS-Richtlinien v3.2.1 testen können, können Sie diese Einschränkungen im „Audit”-Modus bereitstellen, um Verstöße aufzudecken und vor allem selbst eine Gelegenheit zu geben, um sie zu beheben, bevor Sie sie auf Ihrem Kubernetes-Cluster erzwingen.

Hinweis: Sofern nicht anders angegeben, gilt die folgende Anleitung für das Standard-Bundle-Profil pci-dss-v3.2.1. Wenn Sie die Einschränkungen für erweiterte pci-dss-v3.2.1-Bundles anwenden möchten, nachdem Sie das Standard-Bundle angewendet und die im vorherigen Abschnitt zum erweiterten Bundle angegebene Anpassung abgeschlossen haben, wenden Sie das erweiterte Bundle an, indem Sie der Anleitung folgen, aber pci-dss-v3.2.1-extended für pci-dss-v3.2.1 ersetzen.

Sie können diese Richtlinien mit kpt oder Config Sync festlegen, wobei spec.enforcementAction auf dryrun gesetzt ist.

kubectl

1. (Optional) Sehen Sie sich eine Vorschau der Richtlinieneinschränkungen mit kubectl an:

   kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
   

2. Wenden Sie die Richtlinieneinschränkungen mit kubectl an:

   kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
   

   Die Ausgabe sieht so aus:

   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls created
   k8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount created
   k8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth created
   k8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-cloudarmor-backendconfig created
   k8senforceconfigmanagement.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-config-management created
   k8srequirecosnodeimage.constraints.gatekeeper.sh/pci-dss-v3.2.1-nodes-have-consistent-time created
   k8srequiredaemonsets.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-av-daemonset created
   k8srequirenamespacenetworkpolicies.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-namespace-network-policies created
   k8srequiredannotations.constraints.gatekeeper.sh/pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations created
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-managed-by-configmanagement-label created
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-resources-have-required-labels created
   k8srestrictnamespaces.constraints.gatekeeper.sh/pci-dss-v3.2.1-restrict-default-namespace created
   

3. Prüfen Sie, ob Richtlinieneinschränkungen installiert wurden, und prüfen Sie, ob im Cluster Verstöße vorliegen:

   kubectl get -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
   

   Die Ausgabe sieht in etwa so aus:

   NAME                                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls   dryrun               0
   
   NAME                                                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount   dryrun               0
   
   NAME                                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth   dryrun               0
   
   NAME                                                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-cloudarmor-backendconfig   dryrun               0
   
   NAME                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8senforceconfigmanagement.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-config-management   dryrun               0
   
   NAME                                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequirecosnodeimage.constraints.gatekeeper.sh/pci-dss-v3.2.1-nodes-have-consistent-time   dryrun               0
   
   NAME                                                                                 ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredaemonsets.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-av-daemonset   dryrun               0
   
   NAME                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequirenamespacenetworkpolicies.constraints.gatekeeper.sh/pci-dss-v3.2.1-require-namespace-network-policies   dryrun               0
   
   NAME                                                                                                        ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredannotations.constraints.gatekeeper.sh/pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations   dryrun               0
   
   NAME                                                                                                   ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-managed-by-configmanagement-label   dryrun               0
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v3.2.1-resources-have-required-labels              dryrun               0
   
   NAME                                                                                        ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srestrictnamespaces.constraints.gatekeeper.sh/pci-dss-v3.2.1-restrict-default-namespace   dryrun               0
   

KPT

1. Installieren und richten Sie kpt ein. kpt wird in dieser Anleitung verwendet, um Kubernetes-Ressourcen anzupassen und bereitzustellen.

2. Laden Sie das Richtlinien-Bundle für PCI-DSS v3.2.1 von GitHub mit kpt herunter:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
   

3. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Maßnahme der Richtlinien auf dryrun festzulegen:

   kpt fn eval pci-dss-v3.2.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \
     -- enforcementAction=dryrun
   

4. Initialisieren Sie das Arbeitsverzeichnis mit kpt, wodurch eine Ressource erstellt wird, um Änderungen verfolgen zu können:

   cd pci-dss-v3.2.1
   kpt live init
   

5. Wenden Sie die Richtlinieneinschränkungen mit kpt an:

   kpt live apply
   

6. Prüfen Sie, ob Richtlinieneinschränkungen installiert wurden, und prüfen Sie, ob im Cluster Verstöße vorliegen:

   kpt live status --output table --poll-until current
   

   Der Status CURRENT bestätigt die erfolgreiche Installation der Einschränkungen.

Config Sync

1. Installieren und richten Sie kpt ein. kpt wird in dieser Anleitung verwendet, um Kubernetes-Ressourcen anzupassen und bereitzustellen.

Operatoren, die Config Sync zum Bereitstellen von Richtlinien für ihre Cluster verwenden, können die folgende Anleitung verwenden:

1. Wechseln Sie in das Synchronisierungsverzeichnis für Config Sync:

   cd SYNC_ROOT_DIR
   

   Hinweis: Kpt v1.0.0-beta.17 und höher erstellt automatisch eine resourcegroup.yaml-Datei während live init. Diese sollte nicht in Ihr Config Sync-Repository eingecheckt werden. Falls resourcegroup.yaml noch nicht vorhanden ist, fügen Sie es zur Datei .gitignore Ihres Repositorys hinzu.

   So erstellen Sie .gitignore oder hängen es mit resourcegroup.yaml an:

   echo resourcegroup.yaml >> .gitignore
   

2. Erstellen Sie ein dediziertes policies-Verzeichnis:

   mkdir -p policies
   

3. Laden Sie das Richtlinien-Bundle für PCI-DSS v3.2.1 von GitHub mit kpt herunter:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1 policies/pci-dss-v3.2.1
   

4. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Maßnahme der Richtlinien auf dryrun festzulegen:

   kpt fn eval policies/pci-dss-v3.2.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
   

5. (Optional) Sehen Sie sich eine Vorschau der Richtlinieneinschränkungen an, die erstellt werden sollen:

   kpt live init policies/pci-dss-v3.2.1
   kpt live apply --dry-run policies/pci-dss-v3.2.1
   

6. Wenn Ihr Synchronisierungsverzeichnis für Config Sync Kustomize verwendet, fügen Sie policies/pci-dss-v3.2.1 Ihrer Stamm-kustomization.yaml hinzu. Andernfalls entfernen Sie die Datei policies/pci-dss-v3.2.1/kustomization.yaml:

   rm SYNC_ROOT_DIR/policies/pci-dss-v3.2.1/kustomization.yaml
   

7. Übertragen Sie Änderungen per Push in das Config Sync-Repository:

   git add SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
   git commit -m 'Adding PCI-DSS v3.2.1 policy audit enforcement'
   git push
   

8. Prüfen Sie den Status der Installation:

   watch gcloud beta container fleet config-management status --project PROJECT_ID
   

   Der Status SYNCED bestätigt die Installation der Richtlinien.

Richtlinienverstöße ansehen

Sobald die Richtlinieneinschränkungen im Prüfmodus installiert sind, können Verstöße im Cluster in der UI über das Policy Controller-Dashboard angezeigt werden.

Mit kubectl können Sie auch Verstöße im Cluster mit dem folgenden Befehl aufrufen:

kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'

Wenn Verstöße vorhanden sind, kann eine Liste der Verstoßmeldungen pro Einschränkung angezeigt werden; dazu nutzen Sie:

kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'

Erzwingungsaktion für das PCI-DSS v3.2.1-Richtlinien-Bundle ändern

Nachdem Sie die Richtlinienverstöße in Ihrem Cluster überprüft haben, können Sie den Erzwingungsmodus ändern, sodass der Zulassungs-Controller entweder den Modus warn aktiviert oder sogar deny verhindert, dass nicht konforme Ressourcen auf das Cluster angewendet werden.

Warnung: Verwenden Sie die Maßnahme deny mit Bedacht, da sie möglicherweise erforderliche Änderungen blockiert, was zu einer Unterbrechung kritischer Arbeitslasten oder des Clusters führt. Es wird dringend empfohlen, dass Sie nur die Maßnahmen warn oder dryrun in Clustern mit Produktionsarbeitslasten verwenden, wenn Sie neue Einschränkungen testen oder Migrationen wie Plattformupgrades machen. Weitere Informationen zu Maßnahmen finden Sie unter Auditing mit Einschränkungen.

kubectl

1. Verwenden Sie kubectl, um die Maßnahme der Richtlinien auf warn festzulegen:

   kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
   

2. Prüfen Sie, ob die Maßnahme für Richtlinieneinschränkungen aktualisiert wurde:

   kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1
   

KPT

1. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Maßnahme der Richtlinien auf warn festzulegen:

   kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

2. Wenden Sie die Richtlinieneinschränkungen an:

   kpt live apply
   

Config Sync

Operatoren, die Config Sync zum Bereitstellen von Richtlinien für ihre Cluster verwenden, können die folgende Anleitung verwenden:

1. Wechseln Sie in das Synchronisierungsverzeichnis für Config Sync:

   cd SYNC_ROOT_DIR
   

2. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Maßnahme der Richtlinien auf warn festzulegen:

   kpt fn eval policies/pci-dss-v3.2.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

3. Übertragen Sie Änderungen per Push in das Config Sync-Repository:

   git add SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
   git commit -m 'Adding PCI-DSS v3.2.1 policy bundle warn enforcement'
   git push
   

4. Prüfen Sie den Status der Installation:

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Ihr Repository, das in der Spalte SYNCED angezeigt wird, bestätigt die Installation der Richtlinien.

Richtlinienerzwingung testen

Erstellen Sie mit dem folgenden Befehl eine nicht konforme Ressource im Cluster:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: wp-non-compliant
  labels:
    app: wordpress
spec:
  containers:
    - image: wordpress
      name: wordpress
      ports:
      - containerPort: 80
        name: wordpress
EOF

Der Admission-Controller sollte eine Warnung ausgeben, in der die Richtlinienverstöße aufgeführt sind, gegen die diese Ressource verstößt, wie im folgenden Beispiel gezeigt:

Warning: [pci-dss-v3.2.1-restrict-default-namespace] <default> namespace is restricted
pod/wp-non-compliant created

PCI-DSS v3.2.1-Richtlinien-Bundle entfernen

Bei Bedarf kann das Richtlinien-Bundle von PCI-DSS v3.2.1 aus dem Cluster entfernt werden.

kubectl

• Verwenden Sie kubectl, um die Richtlinien zu entfernen:

  kubectl delete constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1
  

KPT

• Entfernen Sie die Richtlinien:

  kpt live destroy
  

Config Sync

Operatoren, die Config Sync zum Bereitstellen von Richtlinien für ihre Cluster verwenden, können die folgende Anleitung verwenden:

1. Übertragen Sie Änderungen per Push in das Config Sync-Repository:

   git rm -r SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
   git commit -m 'Removing PCI-DSS v3.2.1 policies'
   git push
   

2. Prüfen Sie den Status:

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Ihr Repository, das in der Spalte SYNCED angezeigt wird, bestätigt das Entfernen der Richtlinien.