Convalida le app in base ai criteri aziendali in una pipeline CI

Se la tua organizzazione utilizza Anthos Config Management and Policy Controller per gestire i criteri nei relativi cluster Anthos, puoi convalidare la configurazione del deployment di un'app nella pipeline di integrazione continua (CI). Questo tutorial mostra come ottenere questo risultato. La convalida della tua app è utile se sei uno sviluppatore che crea una pipeline CI per un'app o un ingegnere della piattaforma che crea un modello di pipeline CI per più team di app.

I criteri sono una parte importante della sicurezza e della conformità di un'organizzazione. Policy Controller, che fa parte di Anthos Config Management, consente alla tua organizzazione di gestire questi criteri in modo centralizzato e dichiarativo per tutti i tuoi cluster. Come sviluppatore, puoi sfruttare la natura centralizzata e dichiarativa di questi criteri. Puoi utilizzare queste caratteristiche per convalidare la tua app in base a tali criteri il prima possibile nel tuo flusso di lavoro di sviluppo. Conoscere le violazioni dei criteri nella pipeline CI invece che durante il deployment presenta due vantaggi principali: consente di passare ai sistemi di sicurezza e rafforzare il loop di feedback, riducendo il tempo e il costo necessari per correggere tali violazioni.

Questo tutorial utilizza Cloud Build come strumento CI e un repository GitHub di esempio contenente criteri per le dimostrazioni.

Risorse

Questo tutorial utilizza diversi strumenti Kubernetes. Questa sezione spiega cosa sono questi strumenti, come interagiscono tra loro e se è possibile sostituirli con altro.

Gli strumenti che utilizzerai in questo tutorial includono quanto segue:

Policy Controller: Policy Controller è un prodotto Google Cloud che fa parte di Anthos Config Management. Si basa sul progetto open source Open Policy Agent - Gatekeeper. Policy Controller applica i criteri relativi agli oggetti creati in un cluster Kubernetes (ad esempio, impedendo l'utilizzo di un'opzione specifica o l'applicazione di un'etichetta specifica). Tali criteri sono chiamati vincoli I vincoli sono definiti risorse personalizzate Kubernetes. Config Sync ti consente di dichiarare questi vincoli in un repository Git e di applicare i flussi di lavoro di sviluppo tradizionali al processo di gestione dei criteri. Config Sync è disponibile sia come prodotto autonomo che come parte di Anthos Config Management. Per l'implementazione puoi utilizzare Open Policy Agent - Gatekeeper anziché Policy Controller.
GitHub: in questo tutorial utilizziamo GitHub per ospitare i repository Git: uno per un'app di esempio e uno per Anthos Config Management (che contiene i vincoli per Policy Controller). Per semplicità, i due repository sono due cartelle diverse in un unico repository Git. In realtà, sarebbero repository diversi. Puoi utilizzare qualsiasi soluzione Git.
Cloud Build: Cloud Build è la soluzione CI di Google Cloud. In questo tutorial, lo utilizziamo per eseguire i test di convalida. I dettagli dell'implementazione possono variare da un sistema CI a un altro, mentre i concetti descritti in questo tutorial possono essere utilizzati con qualsiasi sistema CI basato su container.
Kustomize: Kustomize è uno strumento di personalizzazione per le configurazioni Kubernetes. Funziona prendendo le configurazioni "di base" e applicando le personalizzazioni. Ti consente di adottare un approccio DRY (Non ripetere te stesso) alle configurazioni Kubernetes. Con Kustomize, mantieni gli elementi comuni a tutti i tuoi ambienti nelle configurazioni di base e crei personalizzazioni per ogni ambiente. In questo tutorial, conserviamo le configurazioni di Kumomize nel repository dell'app e "creiamo" (ad esempio, applichiamo le personalizzazioni) alle configurazioni nella pipeline CI. Puoi utilizzare i concetti descritti in questo tutorial con qualsiasi strumento che produca configurazioni Kubernetes pronte per essere applicate a un cluster (ad esempio, il comando helm template).
Kpt: Kpt è uno strumento per la creazione di flussi di lavoro per le configurazioni di Kubernetes. Kpt ti consente di recuperare, visualizzare, personalizzare, aggiornare, convalidare e applicare configurazioni di Kubernetes. Poiché funziona con i file Git e YAML, è compatibile con la maggior parte degli strumenti esistenti dell'ecosistema Kubernetes. In questo tutorial, utilizziamo kpt nella pipeline CI per recuperare i vincoli dal repository Anthos Config Management e per convalidare le configurazioni di Kubernetes in base a tali vincoli.

Pipeline

La pipeline CI utilizzata in questo tutorial è mostrata nel seguente diagramma:

Pipeline CI per Policy Controller

La pipeline viene eseguita in Cloud Build e i comandi vengono eseguiti in una directory contenente una copia del repository dell'app di esempio. La pipeline inizia generando le configurazioni Kubernetes finali con Kustomize. In seguito, recupera i vincoli da cui eseguire la convalida dal repository Anthos Config Management utilizzando kpt. Infine, utilizza kpt per convalidare le configurazioni di Kubernetes in base a tali vincoli. Per raggiungere questo ultimo passaggio, utilizziamo una specifica funzione di configurazione chiamata gatekeeper, che esegue questa convalida. In questo tutorial, attiverai manualmente la pipeline CI, ma in realtà la configurerai per l'esecuzione dopo un elemento git push nel repository Git.

Obiettivi

Eseguire una pipeline CI per un'app di esempio con Cloud Build.
Osserva che la pipeline ha esito negativo a causa di una violazione dei criteri.
Modifica il repository dell'app di esempio per rispettare i criteri.
Esegui di nuovo la pipeline CI.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Cloud Build

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi.

Al termine di questo tutorial, puoi evitare di continuare con la fatturazione eliminando le risorse che hai creato. Per maggiori dettagli, consulta la sezione Pulizia.

Prima di iniziare

Seleziona o crea un progetto Google Cloud. Nella console Google Cloud, vai alla pagina Gestisci risorse:

Vai a Gestisci risorse
Abilita la fatturazione per il tuo progetto.
Per eseguire i comandi elencati in questo tutorial, apri Cloud Shell:

Vai a Cloud Shell
In Cloud Shell, esegui gcloud config get-value project.

Se il comando non restituisce l'ID del progetto appena selezionato, configura Cloud Shell in modo da utilizzarlo:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.
In Cloud Shell, abilita l'API Cloud Build richiesta:
```
gcloud services enable cloudbuild.googleapis.com
```

Convalidare le configurazioni delle app di esempio

In questa sezione eseguirai una pipeline CI con Cloud Build per un repository di app fornito da noi. Questa pipeline convalida la configurazione di Kubernetes disponibile in quel repository di app di esempio in base ai vincoli disponibili in un repository Anthos Config Management di esempio.

Per convalidare le configurazioni dell'app:

In Cloud Shell, clona il repository dell'app di esempio:

git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

Esegui la pipeline CI con Cloud Build. I log della build vengono visualizzati direttamente in Cloud Shell.

cd anthos-config-management-samples/ci-app/app-repo
gcloud builds submit .

La pipeline che esegui è definita nel file seguente.

ci-app/app-repo/cloudbuild.yaml

Visualizza su GitHub

steps:
- id: 'Prepare config'
  # This step builds the final manifests for the app
  # using kustomize and the configuration files
  # available in the repository.
  name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: '/bin/sh'
  args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
- id: 'Download policies'
  # This step fetches the policies from the Anthos Config Management repository
  # and consolidates every resource in a single file.
  name: 'gcr.io/kpt-dev/kpt'
  entrypoint: '/bin/sh'
  args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git/ci-app/acm-repo/cluster@main constraints
                  && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
- id: 'Validate against policies'
  # This step validates that all resources comply with all policies.
  name: 'gcr.io/kpt-fn/gatekeeper:v0.2'
  args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']

In Policy Controller, i vincoli sono elementi di creazione di modelli di vincolo. I modelli di vincolo contengono il codice Rego effettivo utilizzato per implementare il vincolo. La funzione gcr.io/kpt-fn/gatekeeper richiede che il modello di vincolo e le definizioni di vincolo funzionino. Il repository dei criteri di esempio contiene entrambi, ma in realtà possono essere archiviati in posizioni diverse. Utilizza il comando kpt pkg get secondo le necessità per scaricare sia i modelli sia i vincoli.

Questo tutorial utilizza gcr.io/kpt-fn/gatekeeper con Cloud Build per convalidare le risorse, ma puoi usare altre due alternative:

Utilizza la funzione gcr.io/kpt-fn/gatekeeper con kpt:

kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2

Utilizza lo strumento a riga di comando gator:

gator test -f hydrated-manifests/kpt-manifests.yaml

Dopo alcuni minuti, osserva che la pipeline presenta errori con il seguente errore:

[...]
Step #2 - "Validate against policies": [error] apps/v1/Deployment/nginx-deployment : Deployment objects should have an 'owner' label indicating who created them.
Step #2 - "Validate against policies": violatedConstraint: deployment-must-have-owner
Finished Step #2 - "Validate against policies"
2022/05/11 18:55:18 Step Step #2 - "Validate against policies" finished
2022/05/11 18:55:19 status changed to "ERROR"
ERROR
ERROR: build step 2 "gcr.io/kpt-fn/gatekeeper:v0.2" failed: exit status 1
2022/05/11 18:55:20 Build finished with ERROR status

Il vincolo che la configurazione sta violando è definito nel file seguente. Si tratta di una risorsa personalizzata Kubernetes chiamata K8sRequiredLabels.

ci-app/acm-repo/cluster/deployment-must-have-owner.yaml

Visualizza su GitHub

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: deployment-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels:
      - key: "owner"
    message: "Deployment objects should have an 'owner' label indicating who created them."

Per il modello di vincolo corrispondente, consulta requiredlabels.yaml su GitHub.

Crea da te la configurazione completa di Kubernetes e osserva che l'etichetta owner risulta effettivamente mancante. Per creare la configurazione:
```
kubectl kustomize config/prod
```

Correggi l'app per rispettare le norme aziendali

In questa sezione correggi la violazione delle norme utilizzando Kustomize:

In Cloud Shell, aggiungi una sezione commonLabels al file di base della Kustomization:
```
cat <<EOF >> config/base/kustomization.yaml
commonLabels:
  owner: myself
EOF
```
Crea la configurazione Kubernetes completa e osserva che l'etichetta owner è ora presente:
```
kubectl kustomize config/prod
```

Esegui nuovamente la pipeline CI con Cloud Build:

gcloud builds submit .

Ora la pipeline ha esito positivo con il seguente output:

[...]
Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0"
Step #2 - "Validate against policies": [PASS] "gcr.io/kpt-fn/gatekeeper:v0"
[...]

Esegui la pulizia

In Google Cloud Console, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Scopri le best practice per la gestione dei criteri con Anthos Config Management e GitLab.
Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Centro architettura cloud.