PCI-DSS v4.0-Richtlinieneinschränkungen verwenden

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

Einschränkungen für PCI-DSS v4.0-Richtlinien-Bundles

Name der Einschränkung	Beschreibung der Einschränkung	Einstellungs-IDs
pci-dss-v4.0-require-apps-annotations	Erfordert, dass alle Anwendungen im Cluster die Annotation network-controls/date haben.	2.2.5
pci-dss-v4.0-require-av-daemonset	Erfordert ein Antiviren-DaemonSet.	5.2.1, 5.2.2, 5.2.3, 5.3.1, 5.3.2, 5.3.5
pci-dss-v4.0-require-binauthz	Erfordert den Validierungs-Webhook der Binärautorisierung.	2.2.1, 2.2.4, 6.2.3, 6.3.1, 6.3.2
pci-dss-v4.0-require-cloudarmor-backendconfig	Erzwingt die Google Cloud Armor-Konfiguration für BackendConfig Ressourcen.	6.4.1, 6.4.2
pci-dss-v4.0-require-config-management	Erfordert, dass Config Management mit aktiviertem Drift Prevention und mindestens einem RootSync-Objekt im Cluster ausgeführt wird.	1.2.8, 2.2.6, 5.3.5, 6.3.2, 6.5.1
pci-dss-v4.0-require-default-deny-network-policies	Erfordert, dass jeder im Cluster definierte Namespace eine standardmäßige Ablehnungs-NetworkPolicy für ausgehenden Traffic hat.	1.3.2, 1.4.4
pci-dss-v4.0-require-managed-by-label	Alle Apps müssen ein gültiges app.kubernetes.io/managed-by-Label haben.	1.2.8, 2.2.6, 5.3.5, 6.3.2, 6.5.1
pci-dss-v4.0-require-namespace-network-policies	Erfordert, dass jeder im Cluster definierte Namespace einen NetworkPolicy hat.	1.2.5, 1.2.6, 1.4.1, 1.4.4
pci-dss-v4.0-require-peer-authentication-strict-mtls	Stellt sicher, dass PeerAuthentications keinen strikten mTLS-Modus überschreiben kann.	2.2.7, 4.2.1, 8.3.2
pci-dss-v4.0-require-valid-network-ranges	Schränkt die für ein- und ausgehenden CIDR-Bereiche ein.	1.3.1, 1.3.2, 1.4.2, 1.4.4
pci-dss-v4.0-resources-have-required-labels	Erfordert, dass alle Apps ein bestimmtes Label haben, um die Firewallanforderungen zu erfüllen.	1.2.7
pci-dss-v4.0-restrict-cluster-admin-role	Beschränkt die Verwendung der Rolle cluster-admin.	7.2.1, 7.2.2, 7.2.5, 8.2.4
pci-dss-v4.0-restrict-creation-with-default-serviceaccount	Beschränkt das Erstellen von Ressourcen mithilfe eines Standarddienstkontos. Hat keine Auswirkungen während der Prüfung.	2.2.2
pci-dss-v4.0-restrict-default-namespace	Schränkt die Verwendung des Standard-Namespace für Pods ein.	2.2.3
pci-dss-v4.0-restrict-ingress	Beschränkt das Erstellen von Ingress-Objekten.	1.3.1, 1.4.2, 1.4.4
pci-dss-v4.0-restrict-node-image	Sorgt für eine konsistente und korrekte Zeit auf Knoten, indem nur Container-Optimized OS oder Ubuntu als Betriebssystem-Image zugelassen wird.	10.6.1, 10.6.2, 10.6.3
pci-dss-v4.0-restrict-pods-exec	Beschränkt die Verwendung von pods/exec in Roles und ClusterRoles.	8.6.1
pci-dss-v4.0-restrict-rbac-subjects	Beschränkt die Verwendung von Namen in RBAC-Subjekten auf zulässige Werte.	7.3.2, 8.2.1, 8.2.2, 8.2.4
pci-dss-v4.0-restrict-role-wildcards	Beschränkt die Verwendung von Platzhaltern in Roles und ClusterRoles.	7.3.3, 8.2.4
pci-dss-v4.0-restrict-storageclass	Beschränkt StorageClass auf eine Liste von StorageClass, die standardmäßig verschlüsselt werden.	3.3.2, 3.3.3

Hinweise

1. Installieren und initialisieren Sie die Google Cloud CLI, die 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 Version 1.16.0 oder höher mit der Standardbibliothek der Einschränkungsvorlagen in Ihrem Cluster. 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: "networking.k8s.io"
           version: "v1"
           kind: "NetworkPolicy"
         - group: "admissionregistration.k8s.io"
           version: "v1"
           kind: "ValidatingWebhookConfiguration"
         - group: "storage.k8s.io"
           version: "v1"
           kind: "StorageClass"
   

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

   kubectl apply -f policycontroller-config.yaml
   

Arbeitslast des Clusters für PCI-DSS v4.0 konfigurieren

1. Alle Apps (ReplicaSet, Deployment, StatefulSet, DaemonSet) müssen eine network-controls/date-Annotation mit dem Schema YYYY-MM-DD enthalten.
2. Eine Antivirenlösung ist erforderlich. Standardmäßig ist ein daemonset namens clamav in clamav Namespace vorhanden. Der Name und der Namespace von daemonset können jedoch an Ihre Implementierung in der pci-dss-v4.0-require-av-daemonset-Einschränkung angepasst werden.
3. In pci-dss-v4.0-require-binauthz muss die Binärautorisierung aktiviert und konfiguriert werden.
4. Alle BackendConfig müssen für CloudArmor konfiguriert werden.
5. Config Sync muss vorhanden und aktiviert sein.
6. Für jede im Cluster definierte Namespace gibt es eine standardmäßige Ablehnungs-NetworkPolicy für ausgehenden Traffic. Zulässige Ausnahmen können in pci-dss-v4.0-require-namespace-network-policies spezifisch sein.
7. Die Verwendung von Config Sync für configmanagement.gke.io ist standardmäßig erforderlich, der zulässige Wert app.kubernetes.io/managed-by kann jedoch in der Einschränkung pci-dss-v4.0-enforce-managed-by-configmanagement-label angepasst werden.
8. Jeder im Cluster definierte Namespace muss eine NetworkPolicy haben.
9. Bei Verwendung von Anthos Service Mesh muss ASM PeerAuthentication den strikten mTLS-spec.mtls.mode: STRICT verwenden.
10. Für Ingress und Express können nur zulässige IP-Bereiche verwendet werden. Diese können in pci-dss-v4.0-require-valid-network-ranges angegeben werden.
11. Alle Apps (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.
12. Die Verwendung des ClusterRole-Befehls „cluster-admin“ ist nicht zulässig.
13. Ressourcen können nicht mit dem Standarddienstkonto erstellt werden.
14. Der Standard-Namespace kann nicht für Pods verwendet werden.
15. Es können nur zulässige Ingress-Objekte (Ingress, Gateway und Service vom Typ NodePort und LoadBalancer) erstellt werden. Diese können in pci-dss-v4.0-restrict-ingress angegeben werden.
16. Alle Knoten müssen für eine konsistente Zeit Container-Optimized OS oder Ubuntu für ihr Image verwenden.
17. Die Verwendung des Platzhalterzeichens oder der Berechtigung pods/exec in Roles und ClusterRoles ist nicht zulässig.
18. In RBAC-Bindungen können nur zulässige Subjekte verwendet werden. Ihre Domainnamen können in pci-dss-v4.0-restrict-rbac-subjects angegeben werden.
19. Die standardmäßige Verschlüsselung von StorageClass ist in pci-dss-v4.0-restrict-storageclass erforderlich.

PCI-DSS v4.0-Richtlinien-Bundle prüfen

Mit Policy Controller können Sie Richtlinien für Ihren Kubernetes-Cluster erzwingen. Damit Sie Ihre Arbeitslasten und deren Einhaltung in Bezug auf die in der vorherigen Tabelle beschriebenen PCI-DSS v4.0-Richtlinien einfacher testen können, können Sie diese Einschränkungen im Prüfmodus bereitstellen, um Verstöße aufzudecken und, was noch wichtiger ist, Ihnen die Möglichkeit zu geben, sie zu beheben, bevor Sie sie in Ihrem Kubernetes-Cluster erzwingen.

Sie können diese Richtlinien anwenden, wobei spec.enforcementAction mit kubectl, kpt oder Config Sync 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-v4.0
   

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

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

   Die Ausgabe sieht so aus:

   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v4.0-require-peer-authentication-strict-mtls created
   k8sblockallingress.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-ingress created
   k8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-creation-with-default-serviceaccount created
   k8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v4.0-require-cloudarmor-backendconfig created
   k8senforceconfigmanagement.constraints.gatekeeper.sh/pci-dss-v4.0-require-config-management created
   k8sprohibitrolewildcardaccess.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-role-wildcards created
   k8srequirebinauthz.constraints.gatekeeper.sh/pci-dss-v4.0-require-binauthz created
   k8srequirecosnodeimage.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-node-image created
   k8srequiredaemonsets.constraints.gatekeeper.sh/pci-dss-v4.0-require-av-daemonset created
   k8srequiredefaultdenyegresspolicy.constraints.gatekeeper.sh/pci-dss-v4.0-require-default-deny-network-policies created
   k8srequirenamespacenetworkpolicies.constraints.gatekeeper.sh/pci-dss-v4.0-require-namespace-network-policies created
   k8srequirevalidrangesfornetworks.constraints.gatekeeper.sh/pci-dss-v4.0-require-valid-network-ranges created
   k8srequiredannotations.constraints.gatekeeper.sh/pci-dss-v4.0-require-apps-annotations created
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v4.0-require-managed-by-label created
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v4.0-resources-have-required-labels created
   k8srestrictnamespaces.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-default-namespace created
   k8srestrictrbacsubjects.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-rbac-subjects created
   k8srestrictrolebindings.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-cluster-admin-role created
   k8srestrictrolerules.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-pods-exec created
   k8sstorageclass.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-storageclass created
   

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

   kubectl get constraints -l policycontroller.gke.io/bundleName=pci-dss-v4.0
   

   Die Ausgabe sieht in etwa so aus:

   NAME                                                                                                    ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v4.0-require-peer-authentication-strict-mtls   dryrun               0
   
   NAME                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sblockallingress.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-ingress   dryrun               0
   
   NAME                                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-creation-with-default-serviceaccount   dryrun               0
   
   NAME                                                                                                        ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v4.0-require-cloudarmor-backendconfig   dryrun               0
   
   NAME                                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8senforceconfigmanagement.constraints.gatekeeper.sh/pci-dss-v4.0-require-config-management   dryrun               0
   
   NAME                                                                                           ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sprohibitrolewildcardaccess.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-role-wildcards   dryrun               0
   
   NAME                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequirebinauthz.constraints.gatekeeper.sh/pci-dss-v4.0-require-binauthz   dryrun               0
   
   NAME                                                                                ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequirecosnodeimage.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-node-image   dryrun               0
   
   NAME                                                                               ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredaemonsets.constraints.gatekeeper.sh/pci-dss-v4.0-require-av-daemonset   dryrun               0
   
   NAME                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredannotations.constraints.gatekeeper.sh/pci-dss-v4.0-require-apps-annotations   dryrun               0
   
   NAME                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredefaultdenyegresspolicy.constraints.gatekeeper.sh/pci-dss-v4.0-require-default-deny-network-policies   dryrun               0
   
   NAME                                                                                      ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v4.0-require-managed-by-label         dryrun               0
   k8srequiredlabels.constraints.gatekeeper.sh/pci-dss-v4.0-resources-have-required-labels   dryrun               0
   
   NAME                                                                                                           ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequirenamespacenetworkpolicies.constraints.gatekeeper.sh/pci-dss-v4.0-require-namespace-network-policies   dryrun               0
   
   NAME                                                                                                   ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequirevalidrangesfornetworks.constraints.gatekeeper.sh/pci-dss-v4.0-require-valid-network-ranges   dryrun               0
   
   NAME                                                                                      ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srestrictnamespaces.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-default-namespace   dryrun               0
   
   NAME                                                                                    ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srestrictrbacsubjects.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-rbac-subjects   dryrun               0
   
   NAME                                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srestrictrolebindings.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-cluster-admin-role   dryrun               0
   
   NAME                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srestrictrolerules.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-pods-exec   dryrun               0
   
   NAME                                                                           ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sstorageclass.constraints.gatekeeper.sh/pci-dss-v4.0-restrict-storageclass   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 PCI-DSS v4.0-Richtlinien-Bundle von GitHub mithilfe von kpt herunter:

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

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

   kpt fn eval pci-dss-v4.0 -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-v4.0
   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 erstellen während live init automatisch eine resourcegroup.yaml-Datei, die nicht in Ihr Config Sync-Repository eingecheckt werden sollte. Falls noch nicht vorhanden, fügen Sie resourcegroup.yaml zur Datei .gitignore des Repositorys hinzu.

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

   echo resourcegroup.yaml >> .gitignore
   

2. Erstellen Sie ein dediziertes policies-Verzeichnis:

   mkdir -p policies
   

3. Laden Sie das PCI-DSS v4.0-Richtlinien-Bundle von GitHub mithilfe von kpt herunter:

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

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

   kpt fn eval policies/pci-dss-v4.0 -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-v4.0
   kpt live apply --dry-run policies/pci-dss-v4.0
   

6. Wenn Ihr Synchronisierungsverzeichnis für Config Sync Kustomize verwendet, fügen Sie policies/pci-dss-v4.0 Ihrem Stammverzeichnis kustomization.yaml hinzu. Andernfalls entfernen Sie die Datei policies/pci-dss-v4.0/kustomization.yaml:

   rm SYNC_ROOT_DIR/policies/pci-dss-v4.0/kustomization.yaml
   

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

   git add SYNC_ROOT_DIR/policies/pci-dss-v4.0
   git commit -m 'Adding PCI-DSS v4.0 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

Nachdem die Richtlinieneinschränkungen im Prüfmodus installiert wurden, können Sie Verstöße im Cluster auf der Benutzeroberfläche über das Policy Controller-Dashboard anzeigen.

Sie können auch kubectl verwenden, um Verstöße im Cluster mit dem folgenden Befehl anzusehen:

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

Wenn Verstöße vorliegen, kann eine Liste der Verstoßmeldungen pro Einschränkung aufgerufen werden mit:

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

Erzwingungsaktion für PCI-DSS v4.0-Richtlinien-Bundle ändern

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

Warnung: Die Erzwingungsaktion deny sollte mit Vorsicht verwendet werden, da sie erforderliche Änderungen möglicherweise blockieren und zu einer Unterbrechung kritischer Arbeitslasten oder des Clusters führen kann. Es wird dringend empfohlen, beim Testen neuer Einschränkungen oder beim Durchführen von Migrationen wie Plattformupgrades nur die Erzwingungsaktionen warn oder dryrun für Cluster mit Produktionsarbeitslasten zu verwenden. Weitere Informationen zu Erzwingungsaktionen finden Sie unter Prüfung mithilfe von Einschränkungen.

kubectl

1. Legen Sie mit kubectl die Erzwingungsaktion der Richtlinien auf warn fest:

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

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

   kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v4.0
   

KPT

1. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Erzwingungsaktion 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 Erzwingungsaktion der Richtlinien auf warn festzulegen:

   kpt fn eval policies/pci-dss-v4.0 -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-v4.0
   git commit -m 'Adding PCI-DSS v4.0 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 in der Spalte SYNCED 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 mit den Richtlinienverstößen ausgeben, gegen die diese Ressource verstößt, wie im folgenden Beispiel gezeigt:

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

PCI-DSS v4.0-Richtlinien-Bundle entfernen

Bei Bedarf kann das PCI-DSS v4.0-Richtlinien-Bundle aus dem Cluster entfernt werden.

kubectl

• Verwenden Sie kubectl, um die Richtlinien zu entfernen:

  kubectl delete constraint -l policycontroller.gke.io/bundleName=pci-dss-v4.0
  

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-v4.0
   git commit -m 'Removing PCI-DSS v4.0 policies'
   git push
   

2. Prüfen Sie den Status:

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Ihr in der Spalte SYNCED enthaltenes Repository bestätigt das Entfernen der Richtlinien.