Utilizza vincoli dei criteri PCI-DSS v3.2.1

Policy Controller include una libreria predefinita di modelli di vincolo che possono essere utilizzati con il pacchetto PCI-DSS v3.2.1 per valutare la conformità delle risorse del tuo cluster a fronte di alcuni aspetti della versione 3.2.1 del PCI-DSS (Security Card Industry Data Security Standard).

Il bundle richiede Policy Controller 1.14.0 o versioni successive e include questi vincoli che sono mappati ai seguenti controlli PCI-DSS v3.2.1:

Vincolo	Gestione	Descrizione del vincolo	referenziale	Profilo
pci-dss-v3.2.1-resources-have-required-labels	1,1,4	Garantisce i requisiti di un firewall richiedendo che tutte le app contengano un'etichetta specificata.	No	Standard
pci-dss-v3.2.1-apps-must-have-cert-set-of-annotations	1.1.5, 2.4	Garantisce i requisiti per i controlli di rete richiedendo che tutte le app contengano un'annotazione specificata.	No	Standard
criteri-pci-dss-v3.2.1-request-default-deny-network-policies	1.2, 1.3, 2.2.2	Richiede che a ogni spazio dei nomi definito nel cluster venga applicata una modalità predefinita di negazione NetworkPolicy per il traffico in uscita.	Sì	Estensione
pci-dss-v3.2.1-block-all-ingress	1.2, 1.3	Limita la creazione di oggetti Ingress.	No	Estensione
pci-dss-v3.2.1-request-valid-network-ranges	1.2, 1.3.2	Limita gli intervalli CIDR consentiti per l'utilizzo con traffico in entrata e in uscita.	No	Estensione
criteri-pci-dss-v3.2.1-request-namespace-network-policies	1.2	Richiede che ogni spazio dei nomi definito nel cluster abbia un criterio NetworkPolicy.	Sì	Standard
pci-dss-v3.2.1-enforce-managed-by-configmanagement-label	1.2.2, 8.1.2	Richiede un'etichetta app.kubernetes.io/managed-by= valida su RoleBinding risorse.	No	Standard
pci-dss-v3.2.1-block-creation-with-default-serviceaccount	2.1	Limita la creazione delle risorse utilizzando un account di servizio predefinito.	No	Standard
pci-dss-v3.2.1-restrict-default-namespace	2.1	Impedisce ai pod di utilizzare lo spazio dei nomi predefinito.	No	Standard
pci-dss-v3.2.1-asm-peer-authn-strict-mtls	4.1	L'applicazione forzata di tutti i peerPeers non può sovrascrivere il livello mMTLS in modo rigoroso.	No	Standard
pci-dss-v3.2.1-request-av-daemonset	5.1.1, 5.3	Richiede la presenza di un daemonset di antivirus.	Sì	Standard
pci-dss-v3.2.1-enforce-config-management	5.3, 6.1, 6.4	Applica la presenza e l'abilitazione della gestione della configurazione.	No	Standard
pci-dss-v3.2.1-enforce-cloudarmor-backendconfig	6.5, 6.6	Applica la configurazione di Cloud Armor alle risorse BackendConfig.	No	Standard
pci-dss-v3.2.1-restrict-rbac-subjects	8.1, 8.1.5	Limita l'uso dei nomi nei soggetti RBAC ai valori consentiti.	No	Estensione
pci-dss-v3.2.1-block-secrets-of-type-basic-auth	8.1.5, 8.2.3, 8.5	Limita l'utilizzo dei secret di tipo autenticazione di base.	No	Standard
pci-dss-v3.2.1-nodi-di-tempo-coerente	10.4.1, 10.4.3	Assicura un tempo coerente e corretto sui nodi garantendo l'utilizzo di COS come immagine del sistema operativo.	No	Standard

Vincoli del bundle standard e estesi

Il bundle PCI-DSS v3.2.1 implementa un insieme valutato di requisiti politici per ottenere alcuni aspetti dei controlli PCI-DSS v3.2.1. Oltre alla modifica del carico di lavoro per soddisfare i requisiti del bundle standard, è disponibile anche un insieme facoltativo di vincoli estesi che richiedono la personalizzazione per il tuo ambiente.

Prima di iniziare

1. Installa e inizializza Google Cloud CLI, che fornisce i comandi gcloud e kubectl utilizzati in queste istruzioni. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato.
2. Installa Policy Controller sul cluster con la libreria predefinita di modelli di vincolo. Devi anche abilitare il supporto per i vincoli referenziali, in quanto questo pacchetto contiene vincoli referenziali, elencati nella tabella Panoramica.

Configura Policy Controller per i vincoli referenziali

Avviso :puoi sovrascrivere le modifiche. Se hai già un elemento Config nello spazio dei nomi gatekeeper-system, devi includere tutte le impostazioni di personalizzazione precedenti per mantenere le modifiche.

1. Salva il seguente manifest YAML in un file come policycontroller-config.yaml. Il manifest configura il controller dei criteri per guardare tipi specifici di oggetti.

   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. Applica il manifest policycontroller-config.yaml:

   kubectl apply -f policycontroller-config.yaml
   

Configura il carico di lavoro del cluster per PCI-DSS v3.2.1

Pacchetto standard

1. Tutte le app (ReplicaSet, Deployment, StatefulSet e DaemonSet) devono includere un pci-dss-firewall-audit label con lo schema di pci-dss-[0-9]{4}q[1-4].
2. Tutte le app (ReplicaSet, Deployment, StatefulSet, DaemonSet) devono includere un'annotazione network-controls/date con lo schema di YYYY-MM-DD.
3. Ogni namespace definito nel cluster deve avere un NetworkPolicy.
4. L'uso di Anthos Config Management è obbligatorio. Per impostazione predefinita, è necessario configmanagement.gke.io per Config Management, ma può essere personalizzato nel vincolo pci-dss-v3.2.1-enforce-managed-by-configmanagement-label.
5. Non è possibile creare risorse utilizzando l'account di servizio predefinito.
6. L'impostazione predefinita namespace non può essere utilizzata per i pod.
7. Se utilizzi Anthos Service Mesh, ASM PeerAuthentication deve utilizzare l'autenticazione mTLS restrittiva spec.mtls.mode: STRICT.
8. È necessaria una soluzione antivirus. L'impostazione predefinita è la presenza di un daemonset denominato clamav in pci-dss-av namespace. Tuttavia, il nome e lo spazio dei nomi di daemonset possono essere personalizzati nel vincolo pci-dss-v3.2.1-require-av-daemonset. Per un esempio di esecuzione di clamav in un daemonset, vedi Container ClamAV Kubernetes.
9. La presenza e l'abilitazione di Anthos Config Management sono obbligatori.
10. Tutti gli BackendConfig devono essere configurati per CloudArmor.
11. Non è consentito l'uso di secret di tipo basic-auth.
12. Per un'immagine coerente, tutti i nodi devono utilizzare l'immagine Container-Optimized OS di Google.

Bundle esteso (facoltativo con personalizzazione richiesta)

1. Ogni elemento namespace definito nel cluster ha un valore predefinito NetworkPolicy per il traffico in uscita, le eccezioni consentite possono essere specifiche in pci-dss-v3.2.1-require-namespace-network-policies.
2. È possibile creare solo oggetti Ingress consentiti (Ingress, Gateway e Service tipi di NodePort e LoadBalancer che possono essere specificati in pci-dss-v3.2.1-block-all-ingress.
3. Gli intervalli IP consentiti possono essere utilizzati per Ingress ed Express e possono essere specificati in pci-dss-v3.2.1-require-valid-network-ranges.
4. Solo gli oggetti consentiti possono essere utilizzati nelle associazioni RBAC, i tuoi nomi di dominio possono essere specificati in pci-dss-v3.2.1-restrict-rbac-subjects.

Controlla i criteri PCI-DSS v3.2.1 con Policy Controller

Policy Controller consente di applicare i criteri per il cluster Kubernetes. Per testare i carichi di lavoro e la relativa conformità ai criteri PCI-DSS v3.2.1 descritti nella tabella precedente, puoi eseguire il deployment di questi vincoli in modalità di controllo per scoprire le violazioni e, soprattutto, darti la possibilità di risolverli prima di applicarle al cluster Kubernetes.

Nota: se non diversamente specificato, le seguenti istruzioni si applicano al profilo bundle standard pci-dss-v3.2.1. Per applicare i vincoli del pacchetto esteso pci-dss-v3.2.1, dopo aver applicato il bundle standard e aver completato la personalizzazione specificata nella sezione precedente, applica il bundle esteso seguendo le istruzioni, ma sostituendo pci-dss-v3.2.1-extended con pci-dss-v3.2.1.

Puoi applicare questi criteri con spec.enforcementAction impostato su dryrun utilizzando kubectl, kpt o Config Sync.

kubectl

1. (Facoltativo) Visualizza l'anteprima dei vincoli dei criteri con kubectl:

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

2. Applica i vincoli dei criteri con kubectl:

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

   L'output è il seguente:

   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. Verifica che siano stati installati i vincoli dei criteri e controlla se esistono violazioni nel cluster:

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

   L'output è simile al seguente:

   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. Installa e configura kpt. kpt viene utilizzato in queste istruzioni per personalizzare e sottoporre a deployment le risorse Kubernetes.

2. Scarica il bundle di criteri PCI-DSS v3.2.1 da GitHub utilizzando kpt:

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

3. Esegui la funzione set-enforcement-action kpt per impostare l'applicazione dei criteri su dryrun:

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

4. Inizializza la directory di lavoro con kpt, in modo da creare una risorsa per tenere traccia delle modifiche:

   cd pci-dss-v3.2.1
   kpt live init
   

5. Applica i vincoli dei criteri con kpt:

   kpt live apply
   

6. Verifica che siano stati installati i vincoli dei criteri e controlla se esistono violazioni nel cluster:

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

   Lo stato CURRENT conferma l'installazione dei vincoli.

Config Sync

1. Installa e configura kpt. kpt viene utilizzato in queste istruzioni per personalizzare e sottoporre a deployment le risorse Kubernetes.

2. Se utilizzi Anthos Config Management per la prima volta, abilita Anthos Config Management.

Gli operatori che utilizzano Config Sync per eseguire il deployment dei criteri nei propri cluster possono utilizzare le istruzioni seguenti:

1. Passa alla directory di sincronizzazione per Config Sync:

   cd SYNC_ROOT_DIR
   

   Nota: Kpt v1.0.0-beta.17 e versioni successive creano automaticamente un file resourcegroup.yaml durante il giorno live init che non deve essere controllato nel repository Config Sync. Se non è già presente, aggiungi resourcegroup.yaml al file .gitignore del tuo repository.

   Per creare o aggiungere .gitignore con resourcegroup.yaml:

   echo resourcegroup.yaml >> .gitignore
   

2. Crea una directory policies dedicata:

   mkdir -p policies
   

3. Scarica il bundle di criteri PCI-DSS v3.2.1 da GitHub utilizzando kpt:

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

4. Esegui la funzione set-enforcement-action kpt per impostare l'applicazione dei criteri su dryrun:

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

5. (Facoltativo) Visualizza l'anteprima dei vincoli dei criteri che verranno creati:

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

6. Se la directory di sincronizzazione per Config Sync utilizza Kustomize, aggiungi policies/pci-dss-v3.2.1 alla directory principale kustomization.yaml. In caso contrario, rimuovi il file policies/pci-dss-v3.2.1/kustomization.yaml:

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

7. Esegui il push delle modifiche nel repository 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. Verifica lo stato dell'installazione:

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

   Lo stato SYNCED conferma l'installazione dei criteri.

Visualizza violazioni delle norme

Una volta installati i vincoli dei criteri in modalità di controllo, le violazioni nel cluster possono essere visualizzate nell'interfaccia utente utilizzando la dashboard di Policy Controller.

Puoi anche utilizzare kubectl per visualizzare le violazioni nel cluster utilizzando il seguente comando:

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

Se sono presenti violazioni, un elenco dei messaggi di violazione per vincolo può essere visualizzato con:

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

Applica i criteri PCI-DSS v3.2.1

Dopo aver esaminato le violazioni dei criteri nel cluster, il passaggio successivo prevede l'applicazione di questi criteri in modo che il controller di ammissione blocchi l'applicazione di qualsiasi risorsa non conforme al cluster.

kubectl

1. Utilizza kubectl per impostare l'azione di applicazione dei criteri su deny:

   kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1 -o json | jq '.items[].spec.enforcementAction="deny"' | kubectl apply -f -
   

2. Verifica che l'azione di applicazione dei vincoli dei criteri sia stata aggiornata:

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

kpt

1. Esegui la funzione set-enforcement-action kpt per impostare l'applicazione dei criteri su deny:

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

2. Applica i vincoli dei criteri:

   kpt live apply
   

Config Sync

Gli operatori che utilizzano Config Sync per eseguire il deployment dei criteri nei propri cluster possono utilizzare le istruzioni seguenti:

1. Passa alla directory di sincronizzazione per Config Sync:

   cd SYNC_ROOT_DIR
   

2. Esegui la funzione set-enforcement-action kpt per impostare l'applicazione dei criteri su deny:

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

3. Esegui il push delle modifiche nel repository Config Sync:

   git add SYNC_ROOT_DIR/policies/pci-dss-v3.2.1
   git commit -m 'Enforcing PCI-DSS v3.2.1 policies for GKE'
   git push
   

4. Verifica lo stato dell'installazione:

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Il repository che appare nella colonna SYNCED conferma l'installazione dei criteri.

Applicazione delle norme sui test

Esegui un test rapido per confermare l'applicazione dei criteri e il blocco delle risorse non conformi sul cluster.

Crea una risorsa non conforme sul cluster utilizzando il seguente comando:

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

Il controller di ammissione dovrebbe produrre un errore elencando le violazioni delle norme violate dalla risorsa. Ad esempio:

Error from server (Forbidden): error when creating "STDIN":
admission webhook "validation.gatekeeper.sh" denied the request:
[pci-dss-v3.2.1-restrict-default-namespace] <default> namespace is restricted