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
- Installez et initialisez Google Cloud CLI, qui fournit les commandes
gcloud
etkubectl
utilisées dans ces instructions. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé. - 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
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"
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
- Toutes les applications (
ReplicaSet
,Deployment
,StatefulSet
etDaemonSet
) doivent inclure une annotationnetwork-controls/date
avec le schémaYYYY-MM-DD
. - Vous devez ajouter une solution antivirus. Par défaut, un
daemonset
nomméclamav
est présent dans leclamav
Namespace
; cependant, le nom et l'espace de noms dedaemonset
peut être personnalisé en fonction de votre implémentation dans la contraintepci-dss-v4.0-require-av-daemonset
. - L'activation et la configuration de l'autorisation binaire sont requises dans
pci-dss-v4.0-require-binauthz
. - Tous les
BackendConfig
doivent être configurés pour CloudArmor. - La présence et l'activation de Config Sync sont obligatoires.
- Chaque
Namespace
défini dans le cluster possède unNetworkPolicy
de refus par défaut pour la sortie. Les exceptions autorisées peuvent être spécifiées danspci-dss-v4.0-require-namespace-network-policies
. - L'utilisation de Config Sync pour
configmanagement.gke.io
est requise par défaut. Toutefois, la valeurapp.kubernetes.io/managed-by
autorisée peut être personnalisée dans la contraintepci-dss-v4.0-enforce-managed-by-configmanagement-label
. - Chaque
Namespace
défini dans le cluster doit avoir unNetworkPolicy
. - Si vous utilisez Anthos Service Mesh, PeerAuthentication ASM doit utiliser le protocole mTLS strict
spec.mtls.mode: STRICT
. - 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
. - Toutes les applications (
ReplicaSet
,Deployment
,StatefulSet
etDaemonSet
) doivent inclure unpci-dss-firewall-audit label
avec le schémapci-dss-[0-9]{4}q[1-4]
. - L'utilisation du rôle
ClusterRole
d'administrateur de cluster n'est pas autorisée. - Impossible de créer des ressources à l'aide du compte de service par défaut.
- La valeur
Namespace
par défaut ne peut pas être utilisée pour les pods. - Seuls les objets Ingress autorisés (types
Ingress
,Gateway
etService
deNodePort
etLoadBalancer
) peuvent être créés. Ils peuvent être spécifiés danspci-dss-v4.0-restrict-ingress
. - Tous les nœuds doivent utiliser Container-Optimized OS ou Ubuntu pour leur image afin de garantir une heure cohérente.
- L'utilisation du caractère générique ou de l'autorisation
pods/exec
dansRoles
etClusterRoles
n'est pas autorisée. - 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
. - L'utilisation du chiffrement
StorageClass
par défaut est obligatoire danspci-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
(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
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
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
Installez et configurez kpt. kpt est utilisé dans ces instructions pour personnaliser et déployer les ressources Kubernetes.
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
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surdryrun
:kpt fn eval pci-dss-v4.0 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \ -- enforcementAction=dryrun
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
Appliquez les contraintes de règles avec kpt :
kpt live apply
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
- 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 :
Accédez au répertoire de synchronisation pour Config Sync :
cd SYNC_ROOT_DIR
Pour créer ou ajouter
.gitignore
avecresourcegroup.yaml
:echo resourcegroup.yaml >> .gitignore
Créez un répertoire
policies
dédié :mkdir -p policies
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
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surdryrun
:kpt fn eval policies/pci-dss-v4.0 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
(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
Si votre répertoire de synchronisation pour Config Sync utilise Kustomize, ajoutez
policies/pci-dss-v4.0
à votre fichierkustomization.yaml
racine. Sinon, supprimez le fichierpolicies/pci-dss-v4.0/kustomization.yaml
:rm SYNC_ROOT_DIR/policies/pci-dss-v4.0/kustomization.yaml
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
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.
kubectl
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"}]'
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
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surwarn
:kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
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 :
Accédez au répertoire de synchronisation pour Config Sync :
cd SYNC_ROOT_DIR
Exécutez la fonction kpt
set-enforcement-action
pour définir la mesure coercitive des règles surwarn
:kpt fn eval policies/pci-dss-v4.0 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
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
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 :
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
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.