Utiliser les contraintes liées aux règles PCI-DSS v4.0

Policy Controller est fourni avec une bibliothèque par défaut de modèles de contrainte qui peuvent être utilisés avec le bundle PCI-DSS v4.0 pour évaluer la conformité des ressources de votre cluster par rapport à certains aspects de la norme PCI-DSS (Payment Card Industry Data Security Standard) v4.0.

Contraintes liées au bundle de règles PCI-DSS v4.0

Nom de la contrainte	Description de la contrainte	ID de contrôle
pci-dss-v4.0-require-apps-annotations	Nécessite que toutes les applications du cluster comportent une annotation network-controls/date.	2.2.5
pci-dss-v4.0-require-av-daemonset	Nécessite la présence d'un antivirus 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	Nécessite le webhook d'admission de validation d'autorisation binaire.	2.2.1, 2.2.4, 6.2.3, 6.3.1, 6.3.2
pci-dss-v4.0-require-cloudarmor-backendconfig	Applique la configuration de Google Cloud Armor sur les ressources BackendConfig.	6.4.1, 6.4.2
pci-dss-v4.0-require-config-management	Nécessite que Config Management s'exécute avec la prévention des dérives activées et au moins un objet RootSync sur le cluster.	1.2.8, 2.2.6, 5.3.5, 6.3.2, 6.5.1
pci-dss-v4.0-require-default-deny-network-policies	Nécessite que chaque espace de noms défini dans le cluster ait un NetworkPolicy de refus par défaut pour la sortie.	1.3.2, 1.4.4
pci-dss-v4.0-require-managed-by-label	Toutes les applications doivent disposer d'un libellé app.kubernetes.io/managed-by valide.	1.2.8, 2.2.6, 5.3.5, 6.3.2, 6.5.1
pci-dss-v4.0-require-namespace-network-policies	Nécessite que chaque Namespace défini dans le cluster ait un NetworkPolicy.	1.2.5, 1.2.6, 1.4.1, 1.4.4
pci-dss-v4.0-require-peer-authentication-strict-mtls	S'assure que PeerAuthentications ne peut pas écraser le mode mTLS strict.	2.2.7, 4.2.1, 8.3.2
pci-dss-v4.0-require-valid-network-ranges	Limite les plages CIDR pouvant être utilisées avec l'entrée et la sortie.	1.3.1, 1.3.2, 1.4.2, 1.4.4
pci-dss-v4.0-resources-have-required-labels	Exige que toutes les applications contiennent un libellé spécifié pour répondre aux exigences du pare-feu.	1.2.7
pci-dss-v4.0-restrict-cluster-admin-role	Limite l'utilisation du rôle cluster-admin.	7.2.1, 7.2.2, 7.2.5, 8.2.4
pci-dss-v4.0-restrict-creation-with-default-serviceaccount	Limite la création de ressources à l'aide d'un compte de service par défaut. N'a aucun effet pendant l'audit.	2.2.2
pci-dss-v4.0-restrict-default-namespace	Empêche les pods d'utiliser l'espace de noms par défaut.	2.2.3
pci-dss-v4.0-restrict-ingress	Limite la création d'objets Ingress.	1.3.1, 1.4.2, 1.4.4
pci-dss-v4.0-restrict-node-image	Garantit la cohérence et l'exactitude des heures sur les nœuds en n'autorisant que Container-Optimized OS ou Ubuntu comme image d'OS.	10.6.1, 10.6.2, 10.6.3
pci-dss-v4.0-restrict-pods-exec	Limite l'utilisation de pods/exec dans Roles et ClusterRoles.	8.6.1
pci-dss-v4.0-restrict-rbac-subjects	Limite l'utilisation des noms dans les sujets RBAC aux valeurs autorisées.	7.3.2, 8.2.1, 8.2.2, 8.2.4
pci-dss-v4.0-restrict-role-wildcards	Limite l'utilisation des caractères génériques dans Roles et ClusterRoles.	7.3.3, 8.2.4
pci-dss-v4.0-restrict-storageclass	Limite StorageClass à une liste de StorageClass avec encryption par défaut.	3.3.2, 3.3.3

Avant de commencer

1. Installez et initialisez Google Cloud CLI, qui fournit les commandes gcloud et kubectl utilisées dans ces instructions. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé.
2. Installez Policy Controller v1.16.0 ou version ultérieure sur votre cluster avec la bibliothèque par défaut de modèles de contraintes. Vous devez également activer la compatibilité avec les contraintes référentielles, car ce bundle contient des contraintes référentielles.

Configurer Policy Controller pour les contraintes référentielles

Avertissement : Vous pouvez écraser vos propres modifications. Si vous disposez déjà d'un objet Config dans l'espace de noms gatekeeper-system, vous devez inclure tous les paramètres de personnalisation précédents pour conserver vos modifications.

1. Enregistrez le fichier manifeste YAML suivant dans un fichier sous le nom policycontroller-config.yaml. Le fichier manifeste configure Policy Controller pour surveiller des types d'objets spécifiques.

   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. Appliquez le fichier manifeste policycontroller-config.yaml :

   kubectl apply -f policycontroller-config.yaml
   

Configurer la charge de travail de votre cluster pour la norme PCI DSS v4.0

1. Toutes les applications (ReplicaSet, Deployment, StatefulSet et DaemonSet) doivent inclure une annotation network-controls/date avec le schéma YYYY-MM-DD.
2. Vous devez ajouter une solution antivirus. Par défaut, un daemonset nommé clamav est présent dans le clamav Namespace ; cependant, le nom et l'espace de noms de daemonset peut être personnalisé en fonction de votre implémentation dans la contrainte pci-dss-v4.0-require-av-daemonset.
3. L'activation et la configuration de l'autorisation binaire sont requises dans pci-dss-v4.0-require-binauthz.
4. Tous les BackendConfig doivent être configurés pour CloudArmor.
5. La présence et l'activation de Config Sync sont obligatoires.
6. Chaque Namespace défini dans le cluster possède un NetworkPolicy de refus par défaut pour la sortie. Les exceptions autorisées peuvent être spécifiées dans pci-dss-v4.0-require-namespace-network-policies.
7. L'utilisation de Config Sync pour configmanagement.gke.io est requise par défaut. Toutefois, la valeur app.kubernetes.io/managed-by autorisée peut être personnalisée dans la contrainte pci-dss-v4.0-enforce-managed-by-configmanagement-label.
8. Chaque Namespace défini dans le cluster doit avoir un NetworkPolicy.
9. Si vous utilisez Anthos Service Mesh, PeerAuthentication ASM doit utiliser le protocole mTLS strict spec.mtls.mode: STRICT.
10. Seules les plages d'adresses IP autorisées peuvent être utilisées pour les objets Ingress et Express. Elles peuvent être spécifiées dans pci-dss-v4.0-require-valid-network-ranges.
11. Toutes les applications (ReplicaSet, Deployment, StatefulSet et DaemonSet) doivent inclure un pci-dss-firewall-audit label avec le schéma pci-dss-[0-9]{4}q[1-4].
12. L'utilisation du rôle ClusterRole d'administrateur de cluster n'est pas autorisée.
13. Impossible de créer des ressources à l'aide du compte de service par défaut.
14. La valeur Namespace par défaut ne peut pas être utilisée pour les pods.
15. Seuls les objets Ingress autorisés (types Ingress, Gateway et Service de NodePort et LoadBalancer) peuvent être créés. Ils peuvent être spécifiés dans pci-dss-v4.0-restrict-ingress.
16. Tous les nœuds doivent utiliser Container-Optimized OS ou Ubuntu pour leur image afin de garantir une heure cohérente.
17. L'utilisation du caractère générique ou de l'autorisation pods/exec dans Roles et ClusterRoles n'est pas autorisée.
18. Seuls les sujets autorisés peuvent être utilisés dans les liaisons RBAC. Vos noms de domaine peuvent être spécifiés dans pci-dss-v4.0-restrict-rbac-subjects.
19. L'utilisation du chiffrement StorageClass par défaut est obligatoire dans pci-dss-v4.0-restrict-storageclass.

Auditer le lot de règles PCI-DSS v4.0

Policy Controller vous permet d'appliquer des règles à votre cluster Kubernetes. Pour tester vos charges de travail et leur conformité avec les règles PCI-DSS v4.0 décrites dans le tableau précédent, vous pouvez déployer ces contraintes en mode "audit" pour révéler les cas de non-respect et, plus important, vous donner la possibilité de les corriger avant de les appliquer à votre cluster Kubernetes.

Vous pouvez appliquer ces règles en définissant le paramètre spec.enforcementAction sur dryrun à l'aide de kpt ou de Config Sync.

kubectl

1. (Facultatif) Prévisualisez les contraintes de règle avec kubectl :

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

2. Appliquez les contraintes de règle avec kubectl :

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

   Le résultat est le suivant :

   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. Vérifiez que les contraintes de règles ont été installées et si des cas de non-respect existent dans le cluster :

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

   Le résultat ressemble à ce qui suit :

   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. Installez et configurez kpt. kpt est utilisé dans ces instructions pour personnaliser et déployer les ressources Kubernetes.

2. Téléchargez le bundle de règles PCI-DSS v4.0 depuis GitHub à l'aide de kpt :

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

3. Exécutez la fonction kpt set-enforcement-action pour définir la mesure coercitive des règles sur dryrun :

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

4. Initialisez le répertoire de travail avec kpt, qui crée une ressource pour suivre les modifications :

   cd pci-dss-v4.0
   kpt live init
   

5. Appliquez les contraintes de règles avec kpt :

   kpt live apply
   

6. Vérifiez que les contraintes de règles ont été installées et si des cas de non-respect existent dans le cluster :

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

   L'état CURRENT confirme l'installation correcte des contraintes.

Config Sync

1. Installez et configurez kpt. kpt est utilisé dans ces instructions pour personnaliser et déployer les ressources Kubernetes.

Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :

1. Accédez au répertoire de synchronisation pour Config Sync :

   cd SYNC_ROOT_DIR
   

   Remarque : Kpt v1.0.0-beta.17 et versions ultérieures créent automatiquement un fichier resourcegroup.yaml lors de live init, qui ne devrait pas être enregistré dans votre dépôt Config Sync. Si ce n'est pas déjà fait, ajoutez resourcegroup.yaml au fichier .gitignore de votre dépôt.

   Pour créer ou ajouter .gitignore avec resourcegroup.yaml :

   echo resourcegroup.yaml >> .gitignore
   

2. Créez un répertoire policies dédié :

   mkdir -p policies
   

3. Téléchargez le bundle de règles PCI-DSS v4.0 depuis GitHub à l'aide de kpt :

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

4. Exécutez la fonction kpt set-enforcement-action pour définir la mesure coercitive des règles sur dryrun :

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

5. (Facultatif) Prévisualisez les contraintes de règles à créer :

   kpt live init policies/pci-dss-v4.0
   kpt live apply --dry-run policies/pci-dss-v4.0
   

6. Si votre répertoire de synchronisation pour Config Sync utilise Kustomize, ajoutez policies/pci-dss-v4.0 à votre fichier kustomization.yaml racine. Sinon, supprimez le fichier policies/pci-dss-v4.0/kustomization.yaml :

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

7. Transférez les modifications au dépôt Config Sync :

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

8. Vérifiez l'état de l'installation :

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

   L'état SYNCED confirme l'installation des règles .

Consulter les notifications de non-respect des règles

Une fois les contraintes de règle installées en mode audit, les cas de non-respect du cluster peuvent être visualisés dans l'interface utilisateur à l'aide du tableau de bord Policy Controller.

Vous pouvez également utiliser kubectl pour afficher les cas de non-respect sur le cluster à l'aide de la commande suivante :

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

En cas de non-respect des règles, vous pouvez consulter la liste des messages de non-respect par contrainte avec :

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[]?]'

Modifier la mesure coercitive du bundle de règles PCI-DSS v4.0

Une fois que vous avez examiné les cas de non-respect des règles sur votre cluster, vous pouvez envisager de modifier le mode d'application afin que le contrôleur d'admission génère un avertissement (warn) ou bloque (deny) l'application des ressources non conformes sur le cluster.

Avertissement : la mesure coercitive deny doit être utilisée avec prudence, car elle peut potentiellement bloquer les modifications requises, ce qui entraînera une interruption des charges de travail critiques ou du cluster. Il est fortement recommandé de n'utiliser que les actions d'application warn ou dryrun sur les clusters comportant des charges de travail de production, lorsque vous testez de nouvelles contraintes ou effectuez des migrations telles que la mise à niveau de plates-formes. Pour en savoir plus sur les mesures d'application, consultez la section Effectuer un audit à l'aide de contraintes.

kubectl

1. Utilisez kubectl pour définir la mesure coercitive des règles sur warn :

   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. Vérifiez que la mesure coercitive des contraintes de règle a été mise à jour :

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

kpt

1. Exécutez la fonction kpt set-enforcement-action pour définir la mesure coercitive des règles sur warn :

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

2. Appliquez les contraintes de règles :

   kpt live apply
   

Config Sync

Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :

1. Accédez au répertoire de synchronisation pour Config Sync :

   cd SYNC_ROOT_DIR
   

2. Exécutez la fonction kpt set-enforcement-action pour définir la mesure coercitive des règles sur warn :

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

3. Transférez les modifications au dépôt Config Sync :

   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. Vérifiez l'état de l'installation :

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Le dépôt qui s'affiche dans la colonne SYNCED confirme l'installation des règles.

Tester l'application des règles

Créez une ressource non conforme sur le cluster à l'aide de la commande suivante :

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

Le contrôleur d'admission doit générer un avertissement répertoriant les cas de violation des règles que cette ressource ne respecte pas, comme indiqué dans l'exemple suivant :

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

Supprimer le bundle de règles PCI-DSS v4.0

Si nécessaire, le bundle de règles PCI-DSS v4.0 peut être supprimé du cluster.

kubectl

• Utilisez kubectl pour supprimer les règles :

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

kpt

• Supprimez les règles :

  kpt live destroy
  

Config Sync

Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :

1. Transférez les modifications au dépôt Config Sync :

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

2. Vérifiez l'état :

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Le dépôt qui s'affiche dans la colonne SYNCED confirme la suppression des règles.