Utiliser des contraintes de règle PCI-DSS v3.2.1

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

Contraintes de groupe de règles PCI DSS v3.2.1

Nom de la contrainte	Description de la contrainte	ID de commande	Profil
pci-dss-v3.2.1-resources-have-required-labels	Garantit le respect des exigences d'un pare-feu en exigeant que toutes les applications contiennent une étiquette spécifique.	1.1.4	Standard
pci-dss-v3.2.1-apps-must-have-certain-set-of-annotations	Garantit le respect des exigences liées aux commandes réseau en exigeant que toutes les applications contiennent une annotation spécifique.	1.1.5, 2.4	Standard
pci-dss-v3.2.1-require-default-deny-network-policies	Chaque espace de noms défini dans le cluster doit disposer d'un NetworkPolicy refusé par défaut pour la sortie.	1.2, 1.3, 2.2.2	Développée
pci-dss-v3.2.1-block-all-ingress	Limite la création d'objets d'entrée.	1.2, 1.3	Développée
pci-dss-v3.2.1-require-valid-network-ranges	Limite les plages CIDR autorisées à être utilisées en entrée et en sortie.	1.2, 1.3.2	Développée
pci-dss-v3.2.1-require-namespace-network-policies	Nécessite que chaque espace de noms défini dans le cluster ait un objet NetworkPolicy.	1.2	Standard
pci-dss-v3.2.1-enforce-managed-by-configmanagement-label	Nécessite un libellé app.kubernetes.io/managed-by= valide sur les ressources RoleBinding.	1.2.2, 8.1.2	Standard
pci-dss-v3.2.1-block-creation-with-default-serviceaccount	Limite la création de ressources à l'aide d'un compte de service par défaut.	2.1	Standard
pci-dss-v3.2.1-restrict-default-namespace	Empêche les pods d'utiliser l'espace de noms par défaut.	2.1	Standard
pci-dss-v3.2.1-asm-peer-authn-strict-mtls	L'option "Appliquer toutes les PeerAuthentications" ne peut pas remplacer l'authentification mMTLS stricte.	4.1	Standard
pci-dss-v3.2.1-require-av-daemonset	Nécessite la présence d'un daemonset antivirus.	5.1.1, 5.3	Standard
pci-dss-v3.2.1-enforce-config-management	Appliquez la présence et l'activation de Config Sync.	5.3, 6.1, 6.4	Standard
pci-dss-v3.2.1-enforce-cloudarmor-backendconfig	Appliquez la configuration Cloud Armor sur les ressources BackendConfig.	6,5, 6,6	Standard
pci-dss-v3.2.1-restrict-rbac-subjects	Limite l'utilisation des noms dans les sujets RBAC aux valeurs autorisées.	8.1, 8.1.5	Développée
pci-dss-v3.2.1-block-secrets-of-type-basic-auth	Limite l'utilisation des secrets de type "basic-auth".	8.1.5, 8.2.3, 8.5	Standard
pci-dss-v3.2.1-nodes-have-consistent-time	Assure la cohérence et l'utilisation des temps sur les nœuds en assurant l'utilisation de COS comme image de l'OS.	10.4.1, 10.4.3	Standard

Contraintes de groupe standards et avancées

Le lot PCI-DSS v3.2.1 implémente un ensemble défini d'exigences stratégiques pour effectuer certains aspects des contrôles de la norme PCI-DSS v3.2.1. En plus de modifier votre charge de travail pour répondre aux exigences du bundle Standard, un ensemble facultatif de contraintes étendues est également disponible. Vous devez le personnaliser pour votre environnement.

Avant de commencer

1. Installez et initialisez la 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 1.14.3 ou version ultérieure sur votre cluster avec la bibliothèque par défaut de modèles de contraintes. Vous devez également activer la prise en charge des 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 modifications. Si vous disposez déjà d'un 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: "apps"
           version: "v1"
           kind: "DaemonSet"
         - group: "networking.k8s.io"
           version: "v1"
           kind: "NetworkPolicy"
   

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 v3.2.1

Pack standard

1. 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].
2. Toutes les applications (ReplicaSet, Deployment, StatefulSet, DaemonSet) doivent inclure une annotation network-controls/date avec le schéma YYYY-MM-DD.
3. Chaque namespace défini dans le cluster doit avoir un NetworkPolicy.
4. L'utilisation de Config Sync pour configmanagement.gke.io est obligatoire par défaut, mais les valeurs app.kubernetes.io/managed-by autorisées peuvent être personnalisées dans la contrainte pci-dss-v3.2.1-enforce-managed-by-configmanagement-label.
5. Impossible de créer des ressources à l'aide du compte de service par défaut.
6. La valeur par défaut namespace ne peut pas être utilisée pour les pods.
7. Si vous utilisez Anthos Service Mesh, l'authentification ASM PeerAuthentication doit utiliser le protocole mTLS spec.mtls.mode: STRICT strict.
8. Une solution antivirus est requise. La valeur par défaut est la présence d'un daemonset nommé clamav dans le pci-dss-av namespace. Toutefois, le nom et l'espace de noms de daemonset peuvent être personnalisés en fonction de votre implémentation dans la contrainte pci-dss-v3.2.1-require-av-daemonset.
9. Config Sync doit être présent et activé.
10. Tous les BackendConfig doivent être configurés pour CloudArmor.
11. L'utilisation de secrets de type basic-auth n'est pas autorisée.
12. Tous les nœuds doivent utiliser Google Container-Optimized OS pour leur image afin de garantir la cohérence des temps.

Pack étendu (facultatif, personnalisation requise)

1. Chaque namespace défini dans le cluster est associé à un NetworkPolicy de refus par défaut pour la sortie. Les exceptions autorisées peuvent être spécifiques dans pci-dss-v3.2.1-require-namespace-network-policies.
2. 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-v3.2.1-block-all-ingress.
3. Seules les plages d'adresses IP autorisées peuvent être utilisées pour Ingress et Express. Vous pouvez les spécifier dans pci-dss-v3.2.1-require-valid-network-ranges.
4. 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-v3.2.1-restrict-rbac-subjects.

Auditer le lot de règles PCI-DSS v3.2.1

Policy Controller vous permet d'appliquer des règles à votre cluster Kubernetes. Pour tester vos charges de travail et leur conformité par rapport aux règles PCI-DSS v3.2.1 décrites dans le tableau précédent, vous pouvez déployer ces contraintes en mode "audit" pour détecter les cas de non-respect des règles et, surtout, vous permettre de les corriger avant de les appliquer à votre cluster Kubernetes.

Remarque :Sauf indication contraire, les instructions suivantes s'appliquent au profil de groupe standard pci-dss-v3.2.1. Pour appliquer les contraintes de bundle étendue pci-dss-v3.2.1, après avoir appliqué le bundle standard et terminé la personnalisation spécifiée dans la section précédente, appliquez le bundle étendu en suivant les instructions, mais en remplaçant pci-dss-v3.2.1-extended par pci-dss-v3.2.1.

Vous pouvez appliquer ces règles avec un spec.enforcementAction défini sur dryrun à l'aide de kubectl, kpt ou Config Sync.

kubectl

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

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

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

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

   Le résultat est le suivant :

   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. 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 -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/pci-dss-v3.2.1
   

   Le résultat ressemble à ce qui suit :

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

2. Téléchargez le groupe de règles PCI-DSS v3.2.1 depuis GitHub à l'aide de Kpt:

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

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

   kpt fn eval pci-dss-v3.2.1 -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-v3.2.1
   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 pendant live init, qui ne doit 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 groupe de règles PCI-DSS v3.2.1 depuis GitHub à l'aide de Kpt:

   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. Exécutez la fonction kpt set-enforcement-action pour définir l'action d'application des règles sur dryrun :

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

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

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

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

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

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

   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. 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ègles installées en mode audit, vous pouvez afficher les violations du cluster dans l'interface utilisateur à l'aide du tableau de bord de 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-v3.2.1 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'

En cas de non-respect des règles, la liste des messages de violation par contrainte peut être affichée avec:

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

Modifier l'action d'application du groupe de règles PCI-DSS v3.2.1

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

Avertissement :La mesure coercitive deny doit être utilisée avec précaution, car elle peut bloquer les modifications requises, entraînant une interruption des charges de travail critiques ou du cluster. Nous vous recommandons vivement de n'utiliser que les mesures coercitives warn ou dryrun sur les clusters avec des charges de travail de production, lorsque vous testez de nouvelles contraintes ou lorsque vous effectuez des migrations telles que la mise à niveau de plates-formes. Pour en savoir plus sur les mesures coercitives, consultez Effectuer des audits à l'aide de contraintes.

kubectl

1. Utilisez kubectl pour définir l'action coercitive de la règle sur warn:

   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. 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-v3.2.1
   

kpt

1. Exécutez la fonction kpt set-enforcement-action pour définir l'action d'application 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 l'action d'application des règles sur warn :

   kpt fn eval policies/pci-dss-v3.2.1 -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-v3.2.1
   git commit -m 'Adding PCI-DSS v3.2.1 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 indiquant les cas de non-respect des règles enfreints par cette ressource, comme illustré dans l'exemple suivant:

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

Supprimer le groupe de règles PCI-DSS v3.2.1

Si nécessaire, le groupe de règles PCI-DSS v3.2.1 peut être supprimé du cluster.

kubectl

• Utilisez kubectl pour supprimer les règles:

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

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-v3.2.1
   git commit -m 'Removing PCI-DSS v3.2.1 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.